Z39.50 queries (especially with more results) cause staff client errors

Bug #1713324 reported by Linda Jansova
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Tested in Evergreen 2.12.5a, 2.12.4 and 2.12.3 (where the error appears) and in 2.10.7 and 2.12.1 (where it does not).

Following issues we keep experiencing on our production 2.12.4 server (reported earlier via open-ils-general:
http://libmail.georgialibraries.org/pipermail/open-ils-general/2017-August/014097.html) we have set up a clean installation of 2.12.5a without our data and it seems that the problem – no results showing up for queries with more results - persists.

We have been searching for Author twain and Title huckleberry using in the Library of Congress 739.50 server in our 2.12.5a installation.

Our search has produced the following XUL client error:

Network or server failure. Please check your Internet connection to 192.168.2.214 and choose Retry Network. If you need to enter Offline Mode, choose Ignore Errors in this and subsequent dialogs. If you believe this error is due to a bug in Evergreen and not network problems, please contact your help desk or friendly Evergreen administrators, and give them this information:
method=open-ils.search.z3950.search_class
params=["53cdbfa7d60c70ddcf4ec6d3d40508a4",{"service_array":["loc"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"title":"švejk"},"service":["loc"],"username":[""],"password":[""]}]
THROWN:
null
STATUS:

The corresponding server osrfsys.log is attached in the txt file.

It looks like results are successfully found but not displayed in the desktop staff client.

The same query performed on a 2.10.7 and 2.12.1 system works fine. (The 2.12.1 system used for testing purposes was the community demo server available from http://demo.evergreencatalog.com/eg/staff/ and it showed some 255 results for the above query).

There is also an error in 2.12.5a when it comes to queries like švejk. A search for Title švejk results in client error. However, search for Title švejk and Author hašek is successful as documented in the attached txt file.

A complete successful search for Title švejk alone in 2.10.7 is also documented in the attached txt file.

In 2.12.2 release notes a bug fix related to Z39.50 is mentioned:
„A fix that allows boolean fields to be recognized in queries to the Z39.50 server. “

There have also been some changes in 2.12.0 as described under the „7.3.1. New Access Points for MARC Merge/Overlay Profiles“ heading (please see more details at https://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_12.html).

Could these changes be related to this bug?

We have also tested changing timezones for both server and client (as client timezone awareness has been introduced in 2.12 and there is always a two-hour difference between initial events and the error in the opensrfsys.log). Even when both timezones were set to UTC, the two-hour difference in the log remains.

Revision history for this message
Linda Jansova (skolkova-s) wrote :
Revision history for this message
Linda Jansova (skolkova-s) wrote :

The second txt file is attached.

Revision history for this message
Linda Jansova (skolkova-s) wrote :

And the third one.

summary: - Z39.50 queries (especially with more results) cause desktop client
- errors
+ Z39.50 queries (especially with more results) cause staff client errors
Revision history for this message
Dan Scott (denials) wrote :

After our upgrade to 2.12.4 from 2.10, which included a reinstall on Ubuntu 16.04 and a new ejabberd configuration, we had failures when retrieving Z39.50 searches with lots of records in the result set.

It looks like that problem was due to bug# 1709710 "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses". Can you check on your max_stanza_size and see if increasing that helps resolve the problems you're seeing? That will help confirm that bug.

Revision history for this message
Linda Jansova (skolkova-s) wrote :

Increasing max_stanza_size really resolves the problems! Thank you, Dan!

Revision history for this message
Andrea Neiman (aneiman) wrote :

Can this bug be considered a duplicate of bug 1709710?

Revision history for this message
Linda Jansova (skolkova-s) wrote :

Yes, it can be considered a duplicate of the bug you have mentioned - these two bugs share their solution.

Revision history for this message
Andrea Neiman (aneiman) wrote :

OK, thanks Linda!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.