holds targeter in 1.6.1

[Robert Soulliere]

Evergreen 1.6.1.4
OpenSRF 1.6.2
PostgreSQL 8.4
Linux distro: Ubuntu 10.04 server 64bit

I recently upgrade from 1.6.0 to 1.6.1.4. After the upgrade the holds targeter fails to find a available copy even though:

1) an item is available at the time of the hold placement
2) the user's home or unit is the same as the item's owner and the pickup library is the same.

The staff client hold status is 'Waiting for copy" and Current Copy column indicates "No Copy". The available copy is never found and when attempting to capture the copy status is changed to reshelving and no indication is given to place copy on holds shelf.

The problem occurs whether the title level hold is placed in the staff client or the OPAC.

Other Caveats:
I have the same result on our live server and a test server running 1.6.1.4
I have also loaded our data into a server running 2.0beta with the same data and OS and postgresql version, but the holds targeter works like a charm in 2.0beta.

I have run autogen with the -u option after loading the data.

[Mike Rylander (mrylander)]

Can you grab the log entries for the hold targetter that runs immediately upon hold placement?

[Robert Soulliere (rcsoulliere)]

I attached the log information from osrfsys.log. right after a hold is placed.

The biggest hint seems to be:
[2010-12-21 15:26:40] open-ils.storage [ERR :11233:action.pm:1240:129296014510240108] Processing of hold failed: Can't deflate circ_lib: ARRAY(0x6bfa180) is not a actor::org_unit at /usr/share/perl5/Class/DBI/Search/Basic.pm line 117.

Let me know if you need more log info.

Thanks,
Robert

[Robert Soulliere (rcsoulliere)]

One other interesting note after looking at the errors is that this seems like a similar problem which occurred way back in 2007 to Bill Ott installing on Fedora:
See:
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2007-November/002101.html
and
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2007-November/002064.html

I also found a similar issue discussed on the IRC channel in 2009:
http://www.open-ils.org/irc_logs/openils-evergreen/2009-02/%23openils-evergreen.17-Tue-2009.log

Thanks,
Robert

Robert Soulliere, BA (Hons), MLIS
Systems Librarian
Mohawk College Library
<email address hidden>
Telephone: [phone] x3936
Fax: [phone]
________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of Robert Soulliere [<email address hidden>]
Sent: December 21, 2010 3:05 PM
To: Soulliere, Robert
Subject: [Bug 692717] Re: holds targeter in 1.6.1

I attached the log information from osrfsys.log. right after a hold is
placed.

The biggest hint seems to be:
[2010-12-21 15:26:40] open-ils.storage [ERR :11233:action.pm:1240:129296014510240108] Processing of hold failed: Can't deflate circ_lib: ARRAY(0x6bfa180) is not a actor::org_unit at /usr/share/perl5/Class/DBI/Search/Basic.pm line 117.

Let me know if you need more log info.

Thanks,
Robert

** Attachment added: "hold targeter log information."
   https://bugs.launchpad.net/evergreen/+bug/692717/+attachment/1773010/+files/hold_targeter.log

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/692717

Title:
  holds targeter in 1.6.1

Status in Evergreen - Open ILS:
  New

Bug description:
  Evergreen 1.6.1.4
OpenSRF 1.6.2
PostgreSQL 8.4
Linux distro: Ubuntu 10.04 server 64bit

I recently upgrade from 1.6.0 to 1.6.1.4. After the upgrade the holds targeter fails to find a available copy even though:

1) an item is available at the time of the hold placement
2) the user's home or unit is the same as the item's owner and the pickup library is the same.

The staff client hold status is 'Waiting for copy" and Current Copy column indicates "No Copy". The available copy is never found and when attempting to capture the copy status is changed to reshelving and no indication is given to place copy on holds shelf.

The problem occurs whether the title level hold is placed in the staff client or the OPAC.

Other Caveats:
I have the same result on our live server and a test server running 1.6.1.4
I have also loaded our data into a server running 2.0beta with the same data and OS and postgresql version, but the holds targeter works like a charm in 2.0beta.

I have run autogen with the -u option after loading the data.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/evergreen/+bug/692717/+subscribe

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message. If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this commun...

[Ben Shum (bshum)]

I've tested holds with one of our test 1.6.1.4 servers and they appear to be working just fine so far. No complaints from our live users, so I don't think there's anything wrong with holds at the moment.

Robert, based on your log, can you verify that hold id 2735 in your action.hold_request table has the expected org-units associated with its event? Or to see if there's anything else odd with it. Since that's the id of the hold it's failing on, might be worth investigating the request to make sure it's not containing faulty information.

[Ben Shum (bshum)]

Oh, and also, you said you ran autogen with -u when loading the data (for 2.0?). Did you do this for your 1.6.1.4 systems post-upgrade as well?

Maybe it's an upgrade issue at work?

[Robert Soulliere (rcsoulliere)]

Hi Ben,

I did use the -u option after both upgrades.
Hold id 2735 in action.hold_request table has the expected org-units associated with its
event (pickup_lib, selection_ou, and request_lib) are correct with the org_unit id.

We were using legacy circ JavaScripts scripts on the 1.6.1.4 server and not on the 2.0 server. I tried turning those off on thw 1.6.1.4 server, but still no go.

Robert Soulliere, BA (Hons), MLIS
Systems Librarian
Mohawk College Library
<email address hidden>
Telephone: [phone] x3936
Fax: [phone]
________________________________________
From: <email address hidden> [<email address hidden>] On Behalf Of Ben Shum [<email address hidden>]
Sent: December 22, 2010 1:44 PM
To: Soulliere, Robert
Subject: [Bug 692717] Re: holds targeter in 1.6.1

Oh, and also, you said you ran autogen with -u when loading the data
(for 2.0?). Did you do this for your 1.6.1.4 systems post-upgrade as
well?

Maybe it's an upgrade issue at work?

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/692717

Title:
  holds targeter in 1.6.1

Status in Evergreen - Open ILS:
  New

Bug description:
  Evergreen 1.6.1.4
OpenSRF 1.6.2
PostgreSQL 8.4
Linux distro: Ubuntu 10.04 server 64bit

I recently upgrade from 1.6.0 to 1.6.1.4. After the upgrade the holds targeter fails to find a available copy even though:

1) an item is available at the time of the hold placement
2) the user's home or unit is the same as the item's owner and the pickup library is the same.

The staff client hold status is 'Waiting for copy" and Current Copy column indicates "No Copy". The available copy is never found and when attempting to capture the copy status is changed to reshelving and no indication is given to place copy on holds shelf.

The problem occurs whether the title level hold is placed in the staff client or the OPAC.

Other Caveats:
I have the same result on our live server and a test server running 1.6.1.4
I have also loaded our data into a server running 2.0beta with the same data and OS and postgresql version, but the holds targeter works like a charm in 2.0beta.

I have run autogen with the -u option after loading the data.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/evergreen/+bug/692717/+subscribe

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message. If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited. If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.

[Robert Soulliere (rcsoulliere)]

This turned out to be related to a incorrect version of the Class::DBI perl module installed on my system.
3.0.17 was installed on my system which was too "new". I fixed this by downgrading to 0.96.

Credit to all the folks on the Evergreen IRC channel who tracked this down for me.

I wasn't sure if we just want to close this ticket with "won't fix" or "invalid". I wonder if any actions can be taken from preventing the latest edition of Class::DBI from being installed? I followed a pretty standard installation method:

Install very basic Ubuntu OS Server 64 bit.
Install evergreen from tarball using the prerequisite installer to install perl modules.

Could documentation help -- such as a list of the required perl modules with the latest known supported version or would that list be too extensive? Perhaps this kind of issues is such a rare occurrence, it is unnecessary?

[Dan Scott (denials)]

This problem was fixed long ago in the 2.0 series (via the use of Class::DBI::Frozen::301 and loud clear errors in the logs if neither Class::DBI 0.96 or Class::DBI::Frozen::301 are available), so it should be relatively easy to backport fixes to 1.6.

Alternately, someone could spend the time to update our use of Class::DBI to a modern version, assuming that the API thrashing and drama in that project has settled down.

The question is, who is going to do either of these things?

[Galen Charlton (gmc)]

Hi,

On Dec 23, 2010, at 10:50 AM, Dan Scott wrote:
> Alternately, someone could spend the time to update our use of
> Class::DBI to a modern version, assuming that the API thrashing and
> drama in that project has settled down.

It appears to have settled down, but only because there hasn't been
a new release of Class::DBI for more than three years. Consequently,
supporting Class::DBI 3.0.17 should be safe enough, assuming we don't
decide to switch to a more lively ORM like Rose::DB::Object or DBIx::Class
instead.

[Robert Soulliere (rcsoulliere)]

I attached a patch which I hope will help avoid frustration for anyone doing a clean install of Evergreen 1.6.2. The patch is a basic backport of the DBI fixes for 2.0 and does the following:

Open-ILS/src/perlmods/OpenILS/Application/Storage/CDBI.pm:
- use Class::DBI::Frozen::301 if available or use Class::DBI
- Add log error information to indicate if the installed version of Class::DBI is too "new"

Open-ILS/src/extras/Makefile.Install
- add a force install of Class::DBI::Frozen::301 similar to what is included in the install file for Evergreen 2.0

This is one patch to be applied to the code directory. Let me know if it is better to apply these type of patches separately or if there is anything else I can do to make applying these patches more efficient.

I set this patch up for 1.6.2. Do I need or should I set up patches for older versions of Evergreen in the 1.6 series?

[Mike Rylander (mrylander)]

Committed to rel_1_6[_{1|2}]. Thanks, Robert!