Browse Hold Shelf crashes with "large" number of copies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Won't Fix
|
Low
|
Unassigned |
Bug Description
Evergreen version: rel_2_0 & trunk
OpenSRF version: 1.6.2
PostgreSQL version: 8.4.6
When a user chooses Browse Hold Shelf from the Circulation menu, if the library has a moderately large number of items on the hold shelf, many crash dialogs appear on the screen repeatedly. By moderately large, I mean somewhere around 100 and up. I can reproduce this reliably with 100+ copies on the hold shelf, but it never happens for a location with 25 copies on the hold shelf.
The first and largest of the error dialogs contains information like the following:
Network or server failure. Please check your Internet connection to theory.biblio.org 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=
params=
THROWN:
{"payload"
STATUS:
The smaller contain messages like these:
!! This software has encountered an error. Please tell your friendly system administrator or software developer the following:
fancy_prompt.xul
ReferenceError: js2JSON is not defined
Error adjusting the font size: ReferenceError: js2JSON is not defined
TypeError: Strings is null
Hitting the debug information eventually reveals something like:
Please open a helpdesk ticket and include the following text:
Mon Jan 10 2011 11:41:04 GMT-0500 (EST)
Error retrieving details for hold #7093
{
"desc":"The attempt to query to the DB failed",
"payload":
[
{
}
]
}
Occasionally, the crashiness is so severe that I have to terminate the staff client using the operating system utilities before I can initiate any other work with it.
no longer affects: | evergreen/2.0 |
no longer affects: | evergreen/master |
Changed in evergreen: | |
importance: | Undecided → Low |
With Dan Scott's help in IRC, we were able to make this problem go away by adjusting open-ils.cstore settings in /openils/ conf/opensrf. xml.
By raising the max_requests to 2000 and the max_children to 45, the problem disappeared. It seems the real problem is that we were running out of cstore processes, so the max_children is probably the key setting here.
While doing Browse Hold Shelf for our largest library, 32 cstore child processes were created. This library has 943 copies on the hold shelf as of this writing. If you are a larger consortium with several large members, you'll want to experiment with the cstore max_children setting to find one that works for you. I expect ours will go larger than 45 as multiple libraries browse the hold shelf simultaneously.