[OPEN-ILS-DEV] Z39.50 timeouts...

[Liam Whalen]

I do not know if there is a ticket open yet.  If there is not a ticket then open one, and I will add what I know.

Liam

> On Jan 21, 2014, at 6:54 AM, Tony Bandy <tonyb at ohionet.org> wrote:
> 
> Hi Liam, folks,
>  
> Appreciate the update.  This seems to correspond to another answer someone sent that mentioned some resources only allowed certain search variables.  If they didn’t allow a variable, that would bring back an empty set (right?).  Do you know if there’s an open bug ticket on this?  Should I open one do you think?
>  
> --Tony
>  
> From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Liam Whalen
> Sent: Thursday, January 16, 2014 4:29 PM
> To: Evergreen Development Discussion List
> Subject: Re: [OPEN-ILS-DEV] Z39.50 timeouts...
>  
> Hi Tony,
>  
> We have noticed at Sitka that we can get timeouts when the pubdate is used with certain Z39.50 sources.  This results in an empty result set for that source, which causes problems for the Perl code.  We have a patch in testing to fix the Perl problem.  I am not sure why using pubdate in certain cases causes a timeout.
>  
> Are you using pubdate when you encounter the timeout problems?
>  
> We are running a modified 2.4.0 system.
> 
> Liam Whalen
> BC Libraries Cooperative - Sitka
> Systems Specialist
> 855-383-5761 x1022
> liam.whalen at bc.libraries.coop
> 
> 
> 
>  
> On Jan 16, 2014, at 1:05 PM, Tony Bandy <tonyb at ohionet.org> wrote:
> 
> 
> Hi everyone!
>  
> I put this out on the general list the other day and didn’t see any responses, so just trying to see if any developers have run across this behavior before.  Has anyone else has ever seen any inconsistent Z39.50 “network errors” on their Evergreen clients when attempting to import records?  We’re running 2.4.2 and some of our libraries are reporting in with these network errors.  There’s really no consistent pattern that we’ve been able to discern here. 
>  
> Usually a workaround that’s been having fairly good success for us so far is to uncheck all of the remote Z39.50 servers and then re-add them one at a time (instead of initially selecting the entire group up front).
>  
> Any ideas would be most appreciated!  I initially wondered if maybe the distant servers were not responding soon enough and the staff-client was just throwing up a generic error because a timeout period had passed, but not sure if these timeouts (if they exist) in evergreen are adjustable…..
>  
> --Tony
>  
>  
>  
> Tony Bandy
> tonyb at ohionet.org
> OHIONET
> 1500 West Lane Ave.
> Columbus, OH  43221-3975
> 614-486-2966 x19
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140121/03c12589/attachment-0001.htm>