A period exception has been occuring where TLS would mysteriously fail. Syncornization between the main thread and the PacketReader was originally thought to be the culprit but thanks to Skip Dooley's dedication to the problem it was found to be an issue with the Keep Alive thread spinning up before TLS could successfully complete.
Waiting 15s is not a solution, it should wait for an exact condition... I also fixed a similar big race condition when enabling the compression. The code never waits for the stream to be restarted, for example the binding IQ can be sent before the server sent us the new stream... Please stop waiting arbitrary timeouts and use Condition objects (or wait/notify).
Srgjan Srepfler
June 18, 2006 at 6:57 AM
I don't think this bug should be closed, we're still seeing problems (while using it via mule).
Gaston Dombiak
June 12, 2006 at 11:28 PM
Implemented fixes:
1) Start keep alive thread after TLS (if available) was negotiated or if server is not xmpp 1.0 compliant then after stream header was received
2) Keep alive thread will initially wait for 15 seconds before starting to work
3) Keep alive thread will send a hearbeat every 30 seconds (by default) since the last packet was sent to the server. In other words, connections that are sending stanzas all the time will no need to send heartbeats to keep the connection alive.
A period exception has been occuring where TLS would mysteriously fail. Syncornization between the main thread and the PacketReader was originally thought to be the culprit but thanks to Skip Dooley's dedication to the problem it was found to be an issue with the Keep Alive thread spinning up before TLS could successfully complete.