Bug 15419 - Sipserver problem with stale db handles
Summary: Sipserver problem with stale db handles
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Srdjan Jankovic
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-23 11:44 UTC by Colin Campbell
Modified: 2017-12-07 22:16 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15419 SIP: call auth() subs with timeout, and refresh dbh if need be (2.14 KB, patch)
2016-07-04 05:16 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
Bug 15419 SIP: handle requests with timeout, and refresh dbh if need be (1.84 KB, patch)
2016-09-07 00:47 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
Bug 15419 SIP: handle requests with timeout, and refresh dbh if need be (1.90 KB, patch)
2016-12-02 01:07 UTC, Alex Buckley
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Campbell 2015-12-23 11:44:57 UTC
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
Comment 1 Srdjan Jankovic 2016-07-04 05:16:56 UTC Comment hidden (obsolete)
Comment 2 Srdjan Jankovic 2016-07-04 05:19:33 UTC
To test:
* Start SIP server
* Make a request
* Stop mysql daemon; start mysql daemon
* Make another SIP request - it should not timeout on stale handle
Comment 3 Srdjan Jankovic 2016-09-07 00:47:37 UTC
Created attachment 55273 [details] [review]
Bug 15419 SIP: handle requests with timeout, and refresh dbh if need be
Comment 4 Colin Campbell 2016-09-07 06:36:46 UTC
(In reply to Srdjan Jankovic from comment #3)
> Created attachment 55273 [details] [review] [review]
> Bug 15419 SIP: handle requests with timeout, and refresh dbh if need be

Do we need to timeout. DBI provides the ping method to test this
Comment 5 Srdjan Jankovic 2016-09-07 23:21:05 UTC
If the question is "should we ping instead of timing out" I think pinging every time is too harsh on the database. But I'd like to hear opinions.
Comment 6 Alex Buckley 2016-12-02 01:07:36 UTC
Created attachment 57871 [details] [review]
Bug 15419 SIP: handle requests with timeout, and refresh dbh if need be

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Comment 7 Jonathan Druart 2016-12-12 13:30:45 UTC
Is this still valid for new versions?
I'd expect this to be fixed by bug 14778.
Comment 8 Srdjan Jankovic 2016-12-12 23:06:00 UTC
Yes, that should be the case.
Comment 9 Kyle M Hall 2016-12-30 17:55:10 UTC
(In reply to Srdjan Jankovic from comment #8)
> Yes, that should be the case.

So are you saying this bug should be closed, or it is still needed?
Comment 10 Srdjan Jankovic 2017-01-02 22:59:38 UTC
Closed. Will reopen if needed.