osrf_websocket_translator send requests to the bit-bucket

[Galen Charlton]

If an Apache backend handling osrf_websocket_translator requests loses its XMPP connection (as might happen if it gets forcibly disconnected due to a max_stanza_size violation), it can end up in a state where it accepts requests but never responds to them. This condition is associated with the following log message:

osrf_websocket_translator [WARN:589:transport_session.c:304:1516290118589339] State machine is not connected in send_msg()

If osrf_websocket_translator loses its connection, it should either attempt to reconnect or cause the Apache backend to terminate.

OpenSRF 3.0+

[Bill Erickson (berick)]

Fix pushed:

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lp1744158-ws-exits-on-delivery-failure

I took the (much simpler) route of kicking the client off and allowing the WS process to exit. The client can then reconnect as needed.

I tested navigating around in the browser (via EG web client), stopping services and ejabberd, then trying another websocket request. The request failed and the client was disconnected. I then restarted ejabberd/services and issued more UI commands in the same interface (no page reloads) with success.

[Jason Stephenson (jstephenson)]

Works for me! I was able to reproduce the problem and verify that the branch fixes it.

Before the patch I had to log out of the web staff client to do anything useful after services were restarted. After the patch, logging out and logging back in were not necessary.

I pushed the branch to master and rel_3_0.

Thanks, Bill!