Bug 6620 - Sip Server Output may be buffered
Summary: Sip Server Output may be buffered
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) major (vote)
Assignee: Colin Campbell
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-21 11:14 UTC by Colin Campbell
Modified: 2012-10-25 23:10 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed Patch (1.25 KB, patch)
2011-07-21 11:26 UTC, Colin Campbell
Details | Diff | Splinter Review
no regression after applying patch (1.27 KB, patch)
2011-09-13 14:03 UTC, Ulrich Kleiber
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Campbell 2011-07-21 11:14:52 UTC
Bug fix 5586 correctly removed the linefeed from sipserver output. However as the server writes to stdout which is by default buffered this means that we cannot guarantee that responses are being returned in a timely fashion.

In practice this can be perceived as extremely slow performance by the self-check unit or a cease of functioning altogether (the unit timesout).

In practice reverting 5586 fixes this but as 5586 'does the right thing' this is not a good solution. The proposed solution is that autoflush is specifically set on the output filehandle, to ensure the response message is not buffered.

Note because of the nature of the problem it is hard to reproduce the bug consistently,
Comment 1 Colin Campbell 2011-07-21 11:26:50 UTC
Created attachment 4698 [details] [review]
Proposed Patch
Comment 2 Katrin Fischer 2011-09-01 11:11:18 UTC
I think this is difficult to test. 
Would it be ok to verify that SIP still works after patch was applied?
Comment 3 Colin Campbell 2011-09-01 12:00:29 UTC
Katrin's correct. If your sipserver works fine with your unit then the test is that it dosen't introduce regressions.
If you have 3M (or other) self-checks timing out and restarting or failing this because of timeouts this should fix it.

NB logging can be deceptive as the log gets flushed, so you see the outgoing message even if the packet has not been transmitted to the unit. It looks like the unit is at fault unless you monitor the line itself.
Comment 4 Ulrich Kleiber 2011-09-13 14:03:34 UTC
Created attachment 5415 [details] [review]
no regression after applying patch
Comment 5 Ulrich Kleiber 2011-09-13 14:05:00 UTC
Comment on attachment 5415 [details] [review]
no regression after applying patch

tested with v3.04.04
Comment 6 Chris Cormack 2011-09-14 09:42:17 UTC
Simple patch, pushed
Comment 7 Chris Nighswonger 2011-10-26 18:02:13 UTC
The fix for this bug was published in the 3.4.5 release. If you were the reporter of this bug, please take time to verify the fix and update the status of this bug report accordingly. If the bug is fixed to your satisfaction, please close this report.
Comment 8 Colin Campbell 2011-10-27 18:57:07 UTC
Confirmed works in production on sites where buffered i/o was causing failures