Latest bit of news: Its been about a week since I changed the version of xulrunner being used with the Evergreen 2.3 staff client. We are now running the Evergreen 2.3 staff client (downloaded from the C/W Mars site) with the stock 32-bit version of xulrunner *natively* (NOT using WINE) under CentOS 5.9 (Linux). This is version 10.0.12 of xulrunner. We are running this on both workstations (circulation desk and back office [cataloging mostly]). These workstations are Pentium 4's with 2gig of RAM. Our connection to C/W Mars is via a full T1 line (1.5mbit). The catalogger has reported 0 (*ZERO*) incidents of the (infamous?) "Error in volume_copy_creator.js, g.doc_id is not valid" message. I don't know if this is luck or what.
I have also noticed that the circulation desk system is running better and my logging of memory use suggests that the memory leak tapers off (VIRT memory reaches a plateau). Things still slow down by the afternoon or early evening and restarting the Evergreen 2.3 staff client helps. Our Linux boxes have *never* actually crashed -- Linux deals with excess load or memory starvation much more gracefully than MS-Windows -- Linux might get slow under excessive load, but otherwise keeps chugging along (and recovers once the excessive load is removed -- eg when the overextended process is killed or exits). At Fri, 28 Sep 2012 13:47:02 -0400 Robert Heller <[email protected]> wrote: > > At Fri, 28 Sep 2012 16:12:30 +0000 Alex Reczkowski <[email protected]> > wrote: > > > > > Dear Robert & Jason, > > Just weighing in from Pittsfield (also in C/W MARS) -- we were > > plagued with this error but found that since we upgraded our internet > > line (from 7Mbps/2Mbps to 35Mbps/5Mbps), it has become quite rare. So, > > speed and reliability of the connection seems to have taken care of the > > issue. > > Now that I've typed this, I figure that I probably haven't added much > > to your knowledge, but if you can think of anything I can check or test > > here (since we had the problem and seem to have beaten it), please let > > me know. > > Looking at the bug report, it appears that the problem is a 'race > condition'. Race condition bugs are generally timing related (eg one > process gets ahead of another and thing go south when syncronization is > lost). Anything that makes the timing worse tends to make the race > condition worse or more noticable (occuring more frequently). This > very much seems to be what is going on. > > It also appears that a bug fix is in progress... > > > Sincerely, > > Alex > > > > Alex Reczkowski > > Supervisor, Technical Services > > Berkshire Athenaeum, Pittsfield's Public Library > > 1 Wendell Avenue > > Pittsfield, MA 01201 > > 413-499-9480 ext. 115 > > fax: 413-499-9489 > > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Thu, 27 Sep 2012 12:40:23 -0400 > > From: Robert Heller <[email protected]> > > Subject: [OPEN-ILS-DEV] Frequent error message from Evergreen 2.2 > > Staff Client: "Error in volume_copy_creator.js, g.doc_id is not valid" > > To: open ils dev <[email protected]> > > Cc: Tim Spindler <[email protected]> > > Message-ID: <[email protected]> > > > > I am the IT guy for the Wendell Free Library, a member of the C/W Mars > > library system here in Western Mass. We are getting an error message when > > the librarians try to catalog new books into the library system's database. > > The error message is: > > > > "Error in volume_copy_creator.js, g.doc_id is not valid" > > > > And it comes up when the cataloger tries to load the record for a book to > > edit it (fix incorrect fields, etc.). > > > > We are getting this error message way too frequently, but most of the other > > libraries in our system are not getting this error more than very rarely. > > We are *unique* in that we are using Linux machines to run the staff > > client. We are also one of two libraries that are using a T1 line as our > > network connection to the library system server (the other library also on > > a T1 line is also having this problem as well). > > > > Our machines are small form factor diskless Pentium 4s with 2Gig of RAM. > > They boot over the network and NFS mount their file systems. We are running > > CentOS 5.8 and are using a repackaged version of XULRunner from CentOS 5.7 > > (xulrunner19-1.9.2.26-1) to run the Evergreen 2.2 Staff Client. We are NOT > > using wine to run the MS-Windows version. > > > > Is this a known problem? Is there some workaround? Is there something we > > can do to help fix this problem. The error occurs as part of the > > cataloging process and has pretty much brought our cataloging process to a > > standstill. > > > -- Robert Heller -- 978-544-6933 / [email protected] Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
