Websocket translator responder thread loops on broken jabber socket
Bug #1746577 reported by
Bill Erickson
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenSRF |
Fix Released
|
Medium
|
Unassigned |
Bug Description
OpenSRF 3.0+
If the Jabber socket is disconnected after a request has been relayed to OpenSRF but before its response has been delivered back to the websocket client (e.g. if the Jabber disconnects on max-stanza-size for the response message) the responder thread will loop fast and forever attempting to read data from the broken Jabber socket.
This is the responder thread analog to bug #1744158.
I was able to manually confirm the bug by adding a 10 second sleep to a Perl API, calling the API via websockets, then stopping ejabberd during the sleep. The result is an Apache websocket process spinning on high CPU, strace showing futex() call loops.
Patch en route.
Changed in opensrf: | |
assignee: | nobody → Jason Stephenson (jstephenson) |
Changed in opensrf: | |
importance: | Undecided → Medium |
Changed in opensrf: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Fix pushed:
http:// git.evergreen- ils.org/ ?p=working/ OpenSRF. git;a=shortlog; h=refs/ heads/user/ berick/ lp1746577- ws-gateway- broken- socket- responder- loop
Fix confirmed by applying same test as above and verifying the gateway logs the new disconnect warning, the client shows a "closing websocket" in the browser console, and no looping websocket processes persist. (Note the above test can lead to other opensrf processes looping though because killing ejabberd can have that affect).