Created attachment 3566 [details]
Log file

From campfire:


Andy G.  	
Richard: ok so you can see the server lost the connection to jive before it had the Rhapsody response

Richard T. 	
but is it not an earlier connection that's lost?
Jul 11 	
2:30 PM
Richard T. 	
i assume this is where you say the connection is lost:
Richard T. 	
View paste

[21:51:52.5456] Slim::Web::HTTP::processHTTP (368) Client at 192.168.1.73: disconnected. (sysread: Connection reset by peer)
[21:51:52.5460] Slim::Web::HTTP::closeHTTPSocket (2519) Closing HTTP socket Slim::Web::HTTP::ClientConn=GLOB(0x57b4ad0) with 192.168.1.73:0 (sysread: Connection reset by peer)

Richard T. 	
but the reconnect is on this connection:
Richard T. 	
View paste

[21:51:50.8676] Slim::Web::HTTP::processHTTP (377) HTTP request: from 192.168.1.73:39410 (Slim::Web::HTTP::ClientConn=GLOB(0x5721b50)) for POST HTTP/1.1 /cometd

Andy G. 	
oh hmm

Richard T. 	
looking back in the terminal, the connection that's closed was last mentioned:
Richard T. 	
View paste

[20:35:05.5811] Slim::Web::HTTP::processHTTP (377) HTTP request: from 192.168.1.73:44110 (Slim::Web::HTTP::ClientConn=GLOB(0x57b4ad0)) for POST HTTP/1.1 /cometd

Richard T. 	
so somehow SC is not noticing that connection has closed until after the new one is established.
Jul 11 	
2:35 PM
Andy G. 	
ok yep
Andy G. 	
the reconnect code removes the disconnect timer, but doesn't handle the case where the disconnects happens *after* the reconnect
Jul 11 	
2:40 PM
Andy G. 	
I wonder why the disconnect debug line doesn't show the port number