I am running OpenFire 4.0.1 and have tried Smack 4.2.0-alpha3. Unfortunately, there seems to be a concurrency issue during connection creation, because it is working sometimes. I have not find any hints what could be the cause. I was confronted with the problem already in version 4.2.0-alpha2. The difference is that I got the NoResponseException in this version all the time. Version 4.2.0-alpha3 seems to be a little bit better, but still has some problems. Versions 4.2.0-alpha1 and 4.1.6 are working fine. I hope that this is helpful when narrowing down the problem’s source. I have increased the default packet reply timeout to maximum, but that does not make any difference. I still get the following exception:
org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 9223372036854775807ms (~9223372036854775s). While waiting for successful SASL authentication
at org.jivesoftware.smack.SmackException$NoResponseException.newWith(SmackExceptio n.java:92)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 217)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.ja va:381)
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java :466)
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java :423)
Is this a low latency link between the Smack client and Openfire? If so, could you somehow (artificially) increase the latency? I wonder why I and the daily run integration tests have never run into this, but they are all on either slow boxes or run over “normal” latency links.
Can you provide an XMPP trace when this happens? I wonder how far the SASL mech has gone when this happens. This would be really helpful to further pin down the issue.
Can you recreate it reliable somehow?
That was a good hint…
Adding a delay between connect() and login() leads to a working connection:
I can provide you the messages provided by the debug window when the exception occurrs:
Raw Sent Packets:
<stream:stream xmlns=‘jabber:client’ to=‘middleware’ xmlns:stream=‘http://etherx.jabber.org/streams’ version=‘1.0’ from=‘com.example.nodes.tree.xmpp.skeleton@middleware’ xml:lang=‘en’>
Yz1iaXdzLHI9IDZDXWBgY211SFdfYEpBTHJzfF Y/TVJRU1c8fCA3dlhkNDg4OGI1ZS0wM2M1LTQ4OTgtOGI1ZS03MzM3MDkxYTlhNGUscD16L0tSdk5DWn cyR2ErbS9aZVhNVElGUVRwdEk9
<stream:stream xmlns=‘jabber:client’ to=‘middleware’ xmlns:stream=‘http://etherx.jabber.org/streams’ version=‘1.0’ from=‘com.example.nodes.tree.xmpp.skeleton@middleware’ id=‘5ig3c73265’ xml:lang=‘en’>
Raw Received Packets:
<?xml version='1.0' encoding='UTF-8'?>
cj0gNkNdYGBjbXVIV19gSkFMcnN8Vj9NUlFTVz x8IDd2WGQ0ODg4YjVlLTAzYzUtNDg5OC04YjVlLTczMzcwOTFhOWE0ZSxzPTJsRFZDMVdtanZzaXNoeH hlSytCQUVFZ3oxMytNU0dILGk9NDA5Ng==
<?xml version='1.0' encoding='UTF-8'?>zlib
Could you try 4.2.0-alpha4-SNAPSHOT and report back if this fixes the problem? If it does, then I’m missing something about Java’s Memory Model, so I hope I doesn’t solve the issue.
I have increased the default packet reply timeout to maximum, but that does not make any difference.
Just to be sure: When you used a timeout of 9223372036854775807ms, you didn’t wait > 1 day for the NoResponseException?
If so, then that is what confused me, because then either auhtenticationSuccessful should be true or saslException been set.
I am sorry… It was my fault. Some testing code got it into our productive sources. It is not a good idea to set the packetReplyTimeout for the connection to Long.MAX. This caused an overflow in deadline calculation of SASLAuthentication#authenticate(). I removed it and everything seems to be working now.
Thank you very much for your help!
Thanks for the feedback. I’ve created SMACK-718 as result of this.