UUIDBroadcastCache buffer messages on timeout/severed connections

[digitaldan]

This is related to #1655

Following the same flow as in #1655, if a broadcast message is sent after a client has abruptly disconnected (ctrl-c or timeout for example) but before that client has reconnected, then the message is silently lost. The expected behavior would be that the broadcast cache would retain the message if the client is not connected. As a note, messages sent after the client has reconnected are delivered fine (per #1655), only messages sent while the client is disconnected are lost.

[digitaldan]

One other note, I have tried running this with trace logging and do not see any exceptions in the log.

[jfarcand]

Hi, I agree the could be an issue when a write operation happens but there is no I/O exception thrown by the underlying server, Atmosphere can't hadly do something for it except implementing a ACK protocol with the client (like AtmospherePro is offering). In that case messages would be resent in case the client never received it. But with the current default implementtation and since Jetty/Tomcat/Undertow fail to detect the closed connection, a little bit can be done (this is clearly an issue with the JDK IMO, e.g fail to detect the closed connection).

Can you elaborate about the timeout issue? That one is different and should be in another issue, if the time out happens server side.

[digitaldan]

Thanks, I meant if the client times out, not the server. Yes, I would expect the server to through a IO exception when trying to write to a broken connection. From what I have read this is the only reliable way of detecting if a connection is truly disconnected in Java. I'm surprised Jetty is not throwing something.

[jfarcand]

Changing the title as I don't think messages are lost...they will be cached once the connection throw an IOException

[jfarcand]

Closing as fixed.