From jeff.green.ca at gmail.com Sun Nov 24 11:45:39 2013 From: jeff.green.ca at gmail.com (Jeff Green) Date: Sun, 24 Nov 2013 08:45:39 -0800 Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure Message-ID: After restarting our Evergreen services several weeks ago (due to some slowness), we've been unable to use the MARC Batch Import feature in the staff client. After selecting a known-good MARC file to upload, we click the upload button and the next screen shows all 0's (0 queues, records, etc.) The only error message in the log is as follows: [2013-11-24 08:30:13] open-ils.vandelay [ERR :19607:Vandelay.pm:262:1385310436197012] unable to read MARC file We've tried using multiple computers on multiple networks, various MARC files, and have restarted the Evergreen services several times. I also bumped up the loglevel but didn't find any more useful information. Running on Evergreen 2.2.0 Any help would be greatly appreciated. Here's the full trace for an attempt: [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:Application.pm:130:1385310436197012] CALL: open-ils.vandelay open-ils.vandelay.bib.process_spool a613b75aee15655fd3e302df1f782395, open-ils.auth 2013-11-24 08:30:12 [INFO:19581:oils_auth.c:931:1385310436197012] CALL: open-ils.auth open-ils.auth.session.retrieve - ["a613b75aee15655fd3e302df1f782395",1] open-ils.auth 2013-11-24 08:30:12 [INFO:19581:oils_event.c:46:1385310436197012] Creating new event: SUCCESS open-ils.auth 2013-11-24 08:30:12 [INFO:19581:osrf_app_session.c:1017:1385310436197012] [open-ils.auth] sent 786 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.auth 2013-11-24 08:30:12 [INFO:19581:osrf_stack.c:163:1385310436197012] Message processing duration 0.000733 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_app_session.c:1017:1385310436197012] [open-ils.cstore] sent 180 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.000168 [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] request en-US open-ils.cstore.transaction.begin [] open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_app_session.c:1017:1385310436197012] [open-ils.cstore] sent 372 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.000509 [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] request en-US open-ils.cstore.set_audit_info ["a613b75aee15655fd3e302df1f782395",1,"115"] open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_application.c:1040:1385310436197012] CALL: open-ils.cstore open-ils.cstore.set_audit_info "a613b75aee15655fd3e302df1f782395",1,"115" open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_app_session.c:1017:1385310436197012] [open-ils.cstore] sent 175 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.000573 [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] request en-US open-ils.cstore.direct.vandelay.bib_queue.retrieve 253 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_application.c:1040:1385310436197012] CALL: open-ils.cstore open-ils.cstore.direct.vandelay.bib_queue.retrieve 253 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_app_session.c:1017:1385310436197012] [open-ils.cstore] sent 386 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.001261 [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] checking perms user=1, org=6, perm=CREATE_BIB_IMPORT_QUEUE [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] request en-US open-ils.cstore.json_query.atomic {"from":"au","select":{"au":[{"params":["CREATE_BIB_IMPORT_QUEUE","vbq",253,"6"],"transform":"permission.usr_has_object_perm","alias":"has_perm","column":"id"}]},"where":{"id":"1"}} open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_application.c:1040:1385310436197012] CALL: open-ils.cstore open-ils.cstore.json_query.atomic {"from":"au","select":{"au":[{"params":["CREATE_BIB_IMPORT_QUEUE","vbq",253,"6"],"transform":"permission.usr_has_object_perm","alias":"has_perm","column":"id"}]},"where":{"id":"1"}} open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_app_session.c:1017:1385310436197012] [open-ils.cstore] sent 357 bytes of data to opensrf at private.localhost /open-ils.vandelay_drone_at_localhost_19607 open-ils.cstore 2013-11-24 08:30:12 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.000591 [2013-11-24 08:30:12] open-ils.vandelay [INFO:19607:CStoreEditor.pm:109:1385310436197012] editor[1|1] json_query : returned 1 result(s) [2013-11-24 08:30:13] open-ils.vandelay [ERR :19607:Vandelay.pm:262:1385310436197012] unable to read MARC file open-ils.cstore 2013-11-24 08:30:13 [INFO:19653:osrf_stack.c:163:1385310436197012] Message processing duration 0.000001 [2013-11-24 08:30:13] open-ils.vandelay [INFO:19607:Transport.pm:163:1385310436197012] Message processing duration: 1.021 -- Jeff Green -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.lazar at mnsu.edu Mon Nov 25 12:23:09 2013 From: alexey.lazar at mnsu.edu (Lazar, Alexey Vladimirovich) Date: Mon, 25 Nov 2013 17:23:09 +0000 Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: References: Message-ID: <3CF0DE85-5345-44C3-ACE1-84F03EFD6CF4@mnsu.edu> On 2013-11-24, at 10:45 , Jeff Green wrote: > After restarting our Evergreen services several weeks ago (due to some slowness), we've been unable to use the MARC Batch Import feature in the staff client. Did you make any other changes to the system? Is it possible the slowness cause some system corruption? > We've tried using multiple computers on multiple networks, various MARC files, and have restarted the Evergreen services several times. When you restarted Evergreen services, did you also restart ejabberd? > I also bumped up the loglevel but didn't find any more useful information. Are you seeing any postgresql errors? > Running on Evergreen 2.2.0 Kind of an old version -- many bug fixes and improvements since then, including with speed and security. Do you have a test system where you could try a newer version of Evergreen, like 2.4.something? If yes, try the MARC uploading there. Aleksey Lazar IS Developer and Integrator - PALS http://www.mnpals.org/ From jeff.green.ca at gmail.com Tue Nov 26 19:54:22 2013 From: jeff.green.ca at gmail.com (Jeff Green) Date: Tue, 26 Nov 2013 16:54:22 -0800 Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: <3CF0DE85-5345-44C3-ACE1-84F03EFD6CF4@mnsu.edu> References: <3CF0DE85-5345-44C3-ACE1-84F03EFD6CF4@mnsu.edu> Message-ID: Hi Aleksey. Responses to your questions below. Anyone know what the mechanism is for uploading the MARC file from the staff client into the vandelay module, and what could fail during that process? When I check the relevant Perl I see that the error message is supposed to include the filename, but the log just shows null at that position, therefore I am wondering if the data is even making it to the vandelay module. We did not make any other system changes - only restarted services as it had been a while. Performance degradation over time (3-4 months) is fairly normal for us. Yes, our service restart included apache, memcache, and ejabberd as well as the Evergreen services. We have also since restarted postgres. No new errors in the postgres log, and nothing thrown during the transaction. We'll discuss the possibility of testing on a newer release to see if we can reproduce the issue there. On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich < alexey.lazar at mnsu.edu> wrote: > On 2013-11-24, at 10:45 , Jeff Green wrote: > > > After restarting our Evergreen services several weeks ago (due to some > slowness), we've been unable to use the MARC Batch Import feature in the > staff client. > > Did you make any other changes to the system? Is it possible the slowness > cause some system corruption? > > > We've tried using multiple computers on multiple networks, various MARC > files, and have restarted the Evergreen services several times. > > When you restarted Evergreen services, did you also restart ejabberd? > > > I also bumped up the loglevel but didn't find any more useful > information. > > Are you seeing any postgresql errors? > > > Running on Evergreen 2.2.0 > > Kind of an old version -- many bug fixes and improvements since then, > including with speed and security. Do you have a test system where you > could try a newer version of Evergreen, like 2.4.something? If yes, try the > MARC uploading there. > > Aleksey Lazar > IS Developer and Integrator - PALS > http://www.mnpals.org/ > > -- Jeff Green -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharp at georgialibraries.org Wed Nov 27 13:26:00 2013 From: csharp at georgialibraries.org (Sharp, Chris) Date: Wed, 27 Nov 2013 13:26:00 -0500 (EST) Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: Message-ID: <260055081.229738.1385576760671.JavaMail.root@hagrid.georgialibraries.org> Jeff, The directory on the server is defined in /openils/conf/opensrf.xml in the section (by default it's /tmp). As the inline comments in that file indicate, if you're in a multi-server setup, that directory needs to be a writeable NFS share. In our case it's /openils/var/data/offline/vandelay, but that's probably not a standard location. If you can track down whether the files are being created on the server, that might be the clue you're looking for. Hope that helps, Chris ----- Original Message ----- > From: "Jeff Green" > To: "Alexey Vladimirovich Lazar" > Cc: "" > Sent: Tuesday, November 26, 2013 7:54:22 PM > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure > > > > Hi Aleksey. Responses to your questions below. > > > Anyone know what the mechanism is for uploading the MARC file from > the staff client into the vandelay module, and what could fail > during that process? When I check the relevant Perl I see that the > error message is supposed to include the filename, but the log just > shows null at that position, therefore I am wondering if the data is > even making it to the vandelay module. > > > > We did not make any other system changes - only restarted services as > it had been a while. Performance degradation over time (3-4 months) > is fairly normal for us. > > > Yes, our service restart included apache, memcache, and ejabberd as > well as the Evergreen services. We have also since restarted > postgres. > > > No new errors in the postgres log, and nothing thrown during the > transaction. > > > We'll discuss the possibility of testing on a newer release to see if > we can reproduce the issue there. > > > > On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich < > alexey.lazar at mnsu.edu > wrote: > > > > On 2013-11-24, at 10:45 , Jeff Green < jeff.green.ca at gmail.com > > wrote: > > > After restarting our Evergreen services several weeks ago (due to > > some slowness), we've been unable to use the MARC Batch Import > > feature in the staff client. > > Did you make any other changes to the system? Is it possible the > slowness cause some system corruption? > > > > We've tried using multiple computers on multiple networks, various > > MARC files, and have restarted the Evergreen services several > > times. > > When you restarted Evergreen services, did you also restart ejabberd? > > > > I also bumped up the loglevel but didn't find any more useful > > information. > > Are you seeing any postgresql errors? > > > Running on Evergreen 2.2.0 > > Kind of an old version -- many bug fixes and improvements since then, > including with speed and security. Do you have a test system where > you could try a newer version of Evergreen, like 2.4.something? If > yes, try the MARC uploading there. > > Aleksey Lazar > IS Developer and Integrator - PALS > http://www.mnpals.org/ > > > > > > -- > Jeff Green > > > _______________________________________________ > Evergreen-admin mailing list > Evergreen-admin at list.evergreen-ils.org > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-admin > -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csharp at georgialibraries.org http://pines.georgialibraries.org/ From jeff.green.ca at gmail.com Fri Nov 29 11:36:17 2013 From: jeff.green.ca at gmail.com (Jeff Green) Date: Fri, 29 Nov 2013 08:36:17 -0800 Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: <260055081.229738.1385576760671.JavaMail.root@hagrid.georgialibraries.org> References: <260055081.229738.1385576760671.JavaMail.root@hagrid.georgialibraries.org> Message-ID: Thank you Chris. Yes, I can see files being created in /tmp including recently, verified permissions on /tmp and the files is correct, etc. (we're using a single server instance). So, the MARC file gets uploaded OK, but then when vandelay goes to do its thing it throws the "unable to read MARC file" error. :-/ Other ideas, folks? On Wed, Nov 27, 2013 at 10:26 AM, Sharp, Chris wrote: > Jeff, > > The directory on the server is defined in /openils/conf/opensrf.xml in the > section (by default it's /tmp). As the inline comments > in that file indicate, if you're in a multi-server setup, that directory > needs to be a writeable NFS share. In our case it's > /openils/var/data/offline/vandelay, but that's probably not a standard > location. If you can track down whether the files are being created on the > server, that might be the clue you're looking for. > > Hope that helps, > > Chris > > ----- Original Message ----- > > From: "Jeff Green" > > To: "Alexey Vladimirovich Lazar" > > Cc: "" < > evergreen-admin at list.evergreen-ils.org> > > Sent: Tuesday, November 26, 2013 7:54:22 PM > > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure > > > > > > > > Hi Aleksey. Responses to your questions below. > > > > > > Anyone know what the mechanism is for uploading the MARC file from > > the staff client into the vandelay module, and what could fail > > during that process? When I check the relevant Perl I see that the > > error message is supposed to include the filename, but the log just > > shows null at that position, therefore I am wondering if the data is > > even making it to the vandelay module. > > > > > > > > We did not make any other system changes - only restarted services as > > it had been a while. Performance degradation over time (3-4 months) > > is fairly normal for us. > > > > > > Yes, our service restart included apache, memcache, and ejabberd as > > well as the Evergreen services. We have also since restarted > > postgres. > > > > > > No new errors in the postgres log, and nothing thrown during the > > transaction. > > > > > > We'll discuss the possibility of testing on a newer release to see if > > we can reproduce the issue there. > > > > > > > > On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich < > > alexey.lazar at mnsu.edu > wrote: > > > > > > > > On 2013-11-24, at 10:45 , Jeff Green < jeff.green.ca at gmail.com > > > wrote: > > > > > After restarting our Evergreen services several weeks ago (due to > > > some slowness), we've been unable to use the MARC Batch Import > > > feature in the staff client. > > > > Did you make any other changes to the system? Is it possible the > > slowness cause some system corruption? > > > > > > > We've tried using multiple computers on multiple networks, various > > > MARC files, and have restarted the Evergreen services several > > > times. > > > > When you restarted Evergreen services, did you also restart ejabberd? > > > > > > > I also bumped up the loglevel but didn't find any more useful > > > information. > > > > Are you seeing any postgresql errors? > > > > > Running on Evergreen 2.2.0 > > > > Kind of an old version -- many bug fixes and improvements since then, > > including with speed and security. Do you have a test system where > > you could try a newer version of Evergreen, like 2.4.something? If > > yes, try the MARC uploading there. > > > > Aleksey Lazar > > IS Developer and Integrator - PALS > > http://www.mnpals.org/ > > > > > > > > > > > > -- > > Jeff Green > > > > > > _______________________________________________ > > Evergreen-admin mailing list > > Evergreen-admin at list.evergreen-ils.org > > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-admin > > > > -- > Chris Sharp > PINES System Administrator > Georgia Public Library Service > 1800 Century Place, Suite 150 > Atlanta, Georgia 30345 > (404) 235-7147 > csharp at georgialibraries.org > http://pines.georgialibraries.org/ > -- Jeff Green -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharp at georgialibraries.org Sat Nov 30 13:27:00 2013 From: csharp at georgialibraries.org (Sharp, Chris) Date: Sat, 30 Nov 2013 13:27:00 -0500 (EST) Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: Message-ID: <1962743703.239125.1385836020978.JavaMail.root@hagrid.georgialibraries.org> You might consider upping your loglevel for opensrf in /openils/conf/opensrf_core.xml. That might provide more detail on what's going on. ----- Original Message ----- > From: "Jeff Green" > To: "Chris Sharp" > Cc: "evergreen-admin" , "Alexey Vladimirovich Lazar" > Sent: Friday, November 29, 2013 11:36:17 AM > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure > > > Thank you Chris. > > > Yes, I can see files being created in /tmp including recently, > verified permissions on /tmp and the files is correct, etc. (we're > using a single server instance). > > > So, the MARC file gets uploaded OK, but then when vandelay goes to do > its thing it throws the "unable to read MARC file" error. :-/ > > > Other ideas, folks? > > > > On Wed, Nov 27, 2013 at 10:26 AM, Sharp, Chris < > csharp at georgialibraries.org > wrote: > > > Jeff, > > The directory on the server is defined in /openils/conf/opensrf.xml > in the section (by default it's /tmp). As the > inline comments in that file indicate, if you're in a multi-server > setup, that directory needs to be a writeable NFS share. In our case > it's /openils/var/data/offline/vandelay, but that's probably not a > standard location. If you can track down whether the files are being > created on the server, that might be the clue you're looking for. > > Hope that helps, > > Chris > > > > ----- Original Message ----- > > From: "Jeff Green" < jeff.green.ca at gmail.com > > > To: "Alexey Vladimirovich Lazar" < alexey.lazar at mnsu.edu > > > Cc: "< evergreen-admin at list.evergreen-ils.org >" < > > evergreen-admin at list.evergreen-ils.org > > > Sent: Tuesday, November 26, 2013 7:54:22 PM > > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import > > Failure > > > > > > > > Hi Aleksey. Responses to your questions below. > > > > > > Anyone know what the mechanism is for uploading the MARC file from > > the staff client into the vandelay module, and what could fail > > during that process? When I check the relevant Perl I see that the > > error message is supposed to include the filename, but the log just > > shows null at that position, therefore I am wondering if the data > > is > > even making it to the vandelay module. > > > > > > > > We did not make any other system changes - only restarted services > > as > > it had been a while. Performance degradation over time (3-4 months) > > is fairly normal for us. > > > > > > Yes, our service restart included apache, memcache, and ejabberd as > > well as the Evergreen services. We have also since restarted > > postgres. > > > > > > No new errors in the postgres log, and nothing thrown during the > > transaction. > > > > > > We'll discuss the possibility of testing on a newer release to see > > if > > we can reproduce the issue there. > > > > > > > > On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich < > > alexey.lazar at mnsu.edu > wrote: > > > > > > > > On 2013-11-24, at 10:45 , Jeff Green < jeff.green.ca at gmail.com > > > wrote: > > > > > After restarting our Evergreen services several weeks ago (due to > > > some slowness), we've been unable to use the MARC Batch Import > > > feature in the staff client. > > > > Did you make any other changes to the system? Is it possible the > > slowness cause some system corruption? > > > > > > > We've tried using multiple computers on multiple networks, > > > various > > > MARC files, and have restarted the Evergreen services several > > > times. > > > > When you restarted Evergreen services, did you also restart > > ejabberd? > > > > > > > I also bumped up the loglevel but didn't find any more useful > > > information. > > > > Are you seeing any postgresql errors? > > > > > Running on Evergreen 2.2.0 > > > > Kind of an old version -- many bug fixes and improvements since > > then, > > including with speed and security. Do you have a test system where > > you could try a newer version of Evergreen, like 2.4.something? If > > yes, try the MARC uploading there. > > > > Aleksey Lazar > > IS Developer and Integrator - PALS > > http://www.mnpals.org/ > > > > > > > > > > > > -- > > Jeff Green > > > > > > _______________________________________________ > > Evergreen-admin mailing list > > Evergreen-admin at list.evergreen-ils.org > > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-admin > > > > -- > Chris Sharp > PINES System Administrator > Georgia Public Library Service > 1800 Century Place, Suite 150 > Atlanta, Georgia 30345 > (404) 235-7147 > csharp at georgialibraries.org > http://pines.georgialibraries.org/ > > > > > -- > Jeff Green > > -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csharp at georgialibraries.org http://pines.georgialibraries.org/ From jeff.green.ca at gmail.com Sat Nov 30 18:33:31 2013 From: jeff.green.ca at gmail.com (Jeff Green) Date: Sat, 30 Nov 2013 15:33:31 -0800 Subject: [Evergreen-admin] Staff Client MARC Batch Import Failure In-Reply-To: <1962743703.239125.1385836020978.JavaMail.root@hagrid.georgialibraries.org> References: <1962743703.239125.1385836020978.JavaMail.root@hagrid.georgialibraries.org> Message-ID: 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.. On Saturday, November 30, 2013, Sharp, Chris wrote: > You might consider upping your loglevel for opensrf in > /openils/conf/opensrf_core.xml. That might provide more detail on what's > going on. > > ----- Original Message ----- > > From: "Jeff Green" > > > To: "Chris Sharp" > > Cc: "evergreen-admin" , "Alexey > Vladimirovich Lazar" > > Sent: Friday, November 29, 2013 11:36:17 AM > > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure > > > > > > Thank you Chris. > > > > > > Yes, I can see files being created in /tmp including recently, > > verified permissions on /tmp and the files is correct, etc. (we're > > using a single server instance). > > > > > > So, the MARC file gets uploaded OK, but then when vandelay goes to do > > its thing it throws the "unable to read MARC file" error. :-/ > > > > > > Other ideas, folks? > > > > > > > > On Wed, Nov 27, 2013 at 10:26 AM, Sharp, Chris < > > csharp at georgialibraries.org > wrote: > > > > > > Jeff, > > > > The directory on the server is defined in /openils/conf/opensrf.xml > > in the section (by default it's /tmp). As the > > inline comments in that file indicate, if you're in a multi-server > > setup, that directory needs to be a writeable NFS share. In our case > > it's /openils/var/data/offline/vandelay, but that's probably not a > > standard location. If you can track down whether the files are being > > created on the server, that might be the clue you're looking for. > > > > Hope that helps, > > > > Chris > > > > > > > > ----- Original Message ----- > > > From: "Jeff Green" < jeff.green.ca at gmail.com > > > > To: "Alexey Vladimirovich Lazar" < alexey.lazar at mnsu.edu > > > > Cc: "< evergreen-admin at list.evergreen-ils.org >" < > > > evergreen-admin at list.evergreen-ils.org > > > > Sent: Tuesday, November 26, 2013 7:54:22 PM > > > Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import > > > Failure > > > > > > > > > > > > Hi Aleksey. Responses to your questions below. > > > > > > > > > Anyone know what the mechanism is for uploading the MARC file from > > > the staff client into the vandelay module, and what could fail > > > during that process? When I check the relevant Perl I see that the > > > error message is supposed to include the filename, but the log just > > > shows null at that position, therefore I am wondering if the data > > > is > > > even making it to the vandelay module. > > > > > > > > > > > > We did not make any other system changes - only restarted services > > > as > > > it had been a while. Performance degradation over time (3-4 months) > > > is fairly normal for us. > > > > > > > > > Yes, our service restart included apache, memcache, and ejabberd as > > > well as the Evergreen services. We have also since restarted > > > postgres. > > > > > > > > > No new errors in the postgres log, and nothing thrown during the > > > transaction. > > > > > > > > > We'll discuss the possibility of testing on a newer release to see > > > if > > > we can reproduce the issue there. > > > > > > > > > > > > On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich < > > > alexey.lazar at mnsu.edu > wrote: > > > > > > > > > > > > On 2013-11-24, at 10:45 , Jeff Green < jeff.green.ca at gmail.com > > > > wrote: > > > > > > > After restarting our Evergreen services several weeks ago (due to > > > > some slowness), we've been unable to use the MARC Batch Import > > > > feature in -- Jeff Green -------------- next part -------------- An HTML attachment was scrubbed... URL: