http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15419 Bug ID: 15419 Summary: Sipserver problem with stale db handles Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs@lists.koha-community.org Reporter: colin.campbell@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: colin.campbell@ptfs-europe.com This is a very intermittent problem which appears to manifest in two ways and to date from when C4::Context->dbh stopped using ping way back in commit 4ae3665ad8afb5d283d989c4622a91690e1c4f8a Stale dbh remains active. This was seen on clients which are up for 24 hours, when after 12hours or so of only sending status requests (which do require db access) a real request comes in the database handle which should be refreshed is not but is treated as valid. e.g. a valid patron is entered but the sip server returns it as invalid (the undef returned from the invalid dbh is indistinguishable from returning 0 rows) - In practice I've circumvented this by getting the sepserver to restart all persistent connections at e.g. 6 or 7 am so that the reconnecting devices get a fresh db connection. Another possible solution may be to force a dbh connect in processing a status request. Second manifestation is in authentication I found that intermittently a login was being rejected with 'maintenence' or 'failure' this being the status return from check_api_auth unjustified in both cases. This may be a single occurence, a cluster of occurences and seems to then correct itself I've installed a kludge that does a ping using the dbh returned by context before calling check_api_auth, so far so good, but the intermittent nature of the prob means that I need to continue monitoring -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.