Yes, I did increase the log level, recreate the issue, and then reviewed the logs but I didn't see anything besides the errors copied to the original message. Grr..<span></span><br><br>On Saturday, November 30, 2013, Sharp, Chris  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You might consider upping your loglevel for opensrf in /openils/conf/opensrf_core.xml.  That might provide more detail on what's going on.<br>

<br>
----- Original Message -----<br>
> From: "Jeff Green" <<a href="javascript:;" onclick="_e(event, 'cvml', 'jeff.green.ca@gmail.com')">jeff.green.ca@gmail.com</a>><br>
> To: "Chris Sharp" <<a>csharp@georgialibraries.org</a>><br>
> Cc: "evergreen-admin" <<a>evergreen-admin@list.evergreen-ils.org</a>>, "Alexey Vladimirovich Lazar" <<a>alexey.lazar@mnsu.edu</a>><br>
> Sent: Friday, November 29, 2013 11:36:17 AM<br>
> Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure<br>
><br>
><br>
> Thank you Chris.<br>
><br>
><br>
> Yes, I can see files being created in /tmp including recently,<br>
> verified permissions on /tmp and the files is correct, etc. (we're<br>
> using a single server instance).<br>
><br>
><br>
> So, the MARC file gets uploaded OK, but then when vandelay goes to do<br>
> its thing it throws the "unable to read MARC file" error. :-/<br>
><br>
><br>
> Other ideas, folks?<br>
><br>
><br>
><br>
> On Wed, Nov 27, 2013 at 10:26 AM, Sharp, Chris <<br>
> <a>csharp@georgialibraries.org</a> > wrote:<br>
><br>
><br>
> Jeff,<br>
><br>
> The directory on the server is defined in /openils/conf/opensrf.xml<br>
> in the <open-ils.vandelay> section (by default it's /tmp). As the<br>
> inline comments in that file indicate, if you're in a multi-server<br>
> setup, that directory needs to be a writeable NFS share. In our case<br>
> it's /openils/var/data/offline/vandelay, but that's probably not a<br>
> standard location. If you can track down whether the files are being<br>
> created on the server, that might be the clue you're looking for.<br>
><br>
> Hope that helps,<br>
><br>
> Chris<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Jeff Green" < <a>jeff.green.ca@gmail.com</a> ><br>
> > To: "Alexey Vladimirovich Lazar" < <a>alexey.lazar@mnsu.edu</a> ><br>
> > Cc: "< <a>evergreen-admin@list.evergreen-ils.org</a> >" <<br>
> > <a>evergreen-admin@list.evergreen-ils.org</a> ><br>
> > Sent: Tuesday, November 26, 2013 7:54:22 PM<br>
> > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import<br>
> > Failure<br>
> ><br>
> ><br>
> ><br>
> > Hi Aleksey. Responses to your questions below.<br>
> ><br>
> ><br>
> > Anyone know what the mechanism is for uploading the MARC file from<br>
> > the staff client into the vandelay module, and what could fail<br>
> > during that process? When I check the relevant Perl I see that the<br>
> > error message is supposed to include the filename, but the log just<br>
> > shows null at that position, therefore I am wondering if the data<br>
> > is<br>
> > even making it to the vandelay module.<br>
> ><br>
> ><br>
> ><br>
> > We did not make any other system changes - only restarted services<br>
> > as<br>
> > it had been a while. Performance degradation over time (3-4 months)<br>
> > is fairly normal for us.<br>
> ><br>
> ><br>
> > Yes, our service restart included apache, memcache, and ejabberd as<br>
> > well as the Evergreen services. We have also since restarted<br>
> > postgres.<br>
> ><br>
> ><br>
> > No new errors in the postgres log, and nothing thrown during the<br>
> > transaction.<br>
> ><br>
> ><br>
> > We'll discuss the possibility of testing on a newer release to see<br>
> > if<br>
> > we can reproduce the issue there.<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich <<br>
> > <a>alexey.lazar@mnsu.edu</a> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > On 2013-11-24, at 10:45 , Jeff Green < <a>jeff.green.ca@gmail.com</a> ><br>
> > wrote:<br>
> ><br>
> > > After restarting our Evergreen services several weeks ago (due to<br>
> > > some slowness), we've been unable to use the MARC Batch Import<br>
> > > feature in</blockquote><br><br>-- <br>Jeff Green<br><br><br>