June 2016 - Koha-bugs - lists.koha-community.org

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 --- Comment #35 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Marcell, would you be able to rebase these patches on top of bug 13807? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |13807 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 [Bug 13807] SIPServer Input loop not checking for closed connections reliably -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13807] SIPServer Input loop not checking for closed connections reliably
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |15006 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 [Bug 15006] Need to distinguish client timeout from login timeout -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13807] SIPServer Input loop not checking for closed connections reliably
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 --- Comment #4 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 52854 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52854&action=ed… Bug 13807 Rework main input loop in SIPServer Debugging various problems in SIPServer and control of it, found it could loop on unread buffers (e.g. the LF of a CRLF if it was only expecting CR) making it unresponsive to signals. Reworked the input loop with an eye to removing unnecessary whiles and replacing the while(1) by a while( connection valid) Enhanced the timeout code by wapping in an eval. Moved the logic from SIP_read_packet into the server itself Hopefully this makes the already baroque code easier to navigate and it did seem the server was the logical place for this Removed no longer iused SIP_read_packet from Sip.pm Signed-off-by: Srdjan <srdjan(a)catalyst.net.nz> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13807] SIPServer Input loop not checking for closed connections reliably
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13807] SIPServer Input loop not checking for closed connections reliably
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle(a)bywatersolutions.com --- Comment #3 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Colin, how does this patch work with bug 15006? At the moment they seem to have merge conflicts. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 --- Comment #34 from Kyle M Hall <kyle(a)bywatersolutions.com> --- I like this proposal, but I think we should get Colin's testing and input before setting it to Passed QA. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 --- Comment #33 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 52853 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52853&action=ed… Bug 15006: [COUNTERPATCH] Timeout logic in sip_protocol_loop Instead of adding yet another client timeout, I propose to use the policy timeout that we also communicate in send_acs_status. Although I agree that we perhaps better move it from institution to account/login level, this c/should be done on another report. We may have issues with existing configurations. In order to find a compromise between bug 13432 and the originally proposed 15006 patch, this patch allows you to put a zero in the policy timeout entry in the SIPconfig. The timeout logic is moved to a Sip.pm subroutine. Will add a test :) Test plan: [1] Check timeout after login with policy/timeout > 0. [2] Check timeout after login with policy/timeout = 0. (No timeout!) [3] Check timeout after login with no policy timeout. Fallback to service. [4] Check timeout after login with no policy and service timeout. Should fallback to 30 seconds for both login process and after login. Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 --- Comment #32 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 52852 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52852&action=ed… Bug 15006: [COUNTERPATCH] Add timeout and strikes to raw_transport The code in raw_transport includes setting a $SIG{ALRM}, but did not use it. For consistency, we add an alarm statement here. Similarly, we add the "three strikes" to raw_transport just as telnet_transport does. Note that raw_transport still responds to other requests, but will exit if there is no valid login within three attempts. (If we want more restrictions, add them later?) Test plan: [1] Start sip session with telnet on raw port 6001. Wait until it times out (probably the default 60 seconds). [2] Change SIPconfig.xml: set timeout=5 for service port 6001. Restart SIP and start another telnet 6001 session. Did it timeout within 5 seconds? [3] Start another 6001 session. Give three wrong requests or false login attempts. Does the connection close? Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15006] Need to distinguish client timeout from login timeout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '16

24 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15006 --- Comment #31 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 52851 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52851&action=ed… Bug 15006 Sip separate global from login timeouts Timeout logic has been added to the main sip loop However the timeout parameter was initially for the login process which requires a short duration applying such a brief timeout to the main sip loop causes instability in many selfcheck units Most selfchecks have persistent connections and send a periodic status request at intervals (approx every 5mins appears the norm) The timeout was dropping connections by default every 30secs which for the client appears as a very flakey network This patch adds a separate parameter client_timeout that can be used if you do want to force a disconnect if the client sends no requests for a period. By not defining it you can switch off the timeout in the main loop, I recommend this unless you have a good reason not too. If you do want this behaviour you can at least now set it to a more realistic value (see sample config file) Removed the commented out html entry in the config file, this was dead code born of a misconception and was just a source of confusion for users Signed-off-by: Frederic Demians <f.demians(a)tamil.fr> Signed-off-by: Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0