Timing of the Keep Alive Thread Could Break TLS

Description

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.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Gaston Dombiak
June 12, 2006, 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.

Srgjan Srepfler
June 18, 2006, 6:57 AM

I don't think this bug should be closed, we're still seeing problems (while using it via mule).

Guillaume Perrot
April 14, 2009, 4:32 PM

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).

Fixed

Assignee

Gaston Dombiak

Reporter

Alex Wenckus

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Affects versions

Priority

Critical
Configure