I’m using Smack version 3.2beta2 to send files (Socks5 bytestreams protocol). During stream negotiation the sender goes into an infinite loop (see attached file for reproduction, replace %something% with jabber user names, file paths etc.).
The problem occurs with both OpenFire and Ejabberd XMPP servers.
Last sent package for the sender was an iq containing “”, for which I get a response. Before this packet a stream initiation packet was sent (""),
for which no response was received in the “All Packets” tab. This is probably the cause of the infinite loop. However, in the “Raw Received Packets” tab, the response for the stream initiation packet is present. So, somehow it’s received, but not parsed.
After some investigation I came to the conlusion the cause of the infinite loop might have to do with the PacketReader class using only one thread to deliver incoming packets to listeners. If I recall correctly the disco#info response listener can wait for a result on the si response, but because this was not processed yet and the ListenerExecutor has only one thread, it blocks. I patched this class, such that the ListenerExecutor can use multiple threads instead of only one (see attached file for the diff in PacketReader).
This seemed to resolve the problem, but when I built a jar of the patch and ran it on our acceptance server, the problem reoccurred from time to time. My guess is there still is a race condition somewhere, but I can’t figure it out at the moment. Perhaps the root cause is different from what I thought, can someone help me with this?
Thank you very much in advance!