Currently in sleek it's possible that the send queue could become very large. If a client is disconnected with items still pending in the send queue the following defects occur:
1) Stream initialization on reconnect is interrupted by the emptying of the queue
2) Messages are not cashed to be sent after the reconnected session starts.
This occurs because sleek uses the same send queue for both stream initialization as well as for sending regular iq/messages.
To fix this I have created a new method to send session initialization messages that does not depend on the send thread. The send thread now will not start processing outgoing messages until the session_started_event is set. This is similar to the how sessions are initialized in the smack client. This new method also guarantees that only session initialization messages are sent during stream negotiation.
Currently in sleek it's possible that the send queue could become very large. If a client is disconnected with items still pending in the send queue the following defects occur: 1) Stream initialization on reconnect is interrupted by the emptying of the queue 2) Messages are not cashed to be sent after the reconnected session starts.
This occurs because sleek uses the same send queue for both stream initialization as well as for sending regular iq/messages.
To fix this I have created a new method to send session initialization messages that does not depend on the send thread. The send thread now will not start processing outgoing messages until the session_started_event is set. This is similar to the how sessions are initialized in the smack client. This new method also guarantees that only session initialization messages are sent during stream negotiation.
patch is available in the following 2 commits: http://github.com/macdiesel/SleekXMPP/commit/c56a6d4f1fa72f548435f5177902d437e8b83026 http://github.com/macdiesel/SleekXMPP/commit/2e31baf67dae6c039751aed83bba15072595a8b3