Great to hear Gaston,
I hope this will solve problems we are encountering while using the Mule ESB XMPP provider. On a side note, it’‘s using Smack 1.5, are API’'s used in 1.5 compatible with 2.0.x or the nightly builds?
Gaston,
Looked at your “fix”. A delay in the run method of KeepAlive task! Sorry that is pretty lame, sure it will work but inserting a delay to correct any software problem is generally a crutch.
The problem:
Currently (Smack 2.2), the KeepAlive task is started in the PacketWriter constructor. The constructor is called in the init method of XMPPConnection.
The other problem child in PacketWriter is “startup” but I wil discuss that in another thread. The startup method is called also from init.
When using TLS, everntually proceedTLSReceived in XMPPConnection will be called. It calls the Sun method startHandshake from which yu do not have control over writing object or its stream and therefore can not synchronize with keepalive task. This is the one that usually can get a space injected into it. Even if the KeepAlive delay is 10 seconds or with a “15 second delay” if the code is running very, very slowly due to heavy processor load, it will STILL FAIL! Thus my famous saying “If it can happen it will happen!”
So the theory is why try and KeepAlive a connection which is not yet fully succesfull?
My solution:
Note shortly after the ((SSLSocket) socket).startHandshake(); there is a call into PacketWriter setWriter, even thought the writer object was already captured in the constructor! Good thing too cause the write is needed by the KeepAlive task which has already been running at this point! Anyway,
Take the code which starts the KeepAlive task out of the constructor.
Insert the code in the setWriter method.
Now the KeepAlive task is not started till the handshake is complete.
Even with a 100 ms KeepAlive and a heavily loaded machine I have not seen this fail.
Skip
Hey Skip,
Thanks for your feedback. The code you saw was a temp fix so that people that were having that problem could quickly use a workaround. I just finished the final fix that includes a few improvements.
Implemented fixes:
-
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
-
Keep alive thread will initially wait for 15 seconds before starting to work
-
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.
Regards,
– Gato
Problem resolved!
I tested with the new Smack version.
I cannot get the error anymore!
Cheers!
My colleague has tried the new smack version and it seems we’‘re still getting the same error. Perhaps it’‘s something different altogether and connected to the Mule ESB. Could someone at jive create a VMWare image with wildfire.war and jboss AS (4.0.4 GA, one instance with the ejb3 profile one the default one and others if people ask) so we can try and create a test environment? I would create one but I don’'t have any experience with it (nor a licence if it requires a commercial one). I could then deploy my app on it and report more detailed bug reports (and it would be usefull test platform as well).
There is still a problem in PacketReader.java. See
http://www.jivesoftware.org/community/thread.jspa?threadID=19926&tstart=0
May or may not be what you are experiencing. The actual exception thrown depends on timing, but does cause this exception in server.
There was also a concurrency problem in the server, it is fixed in 2.6.2 best I can tell.
Skip
Is there still some development going on in order to squish this bug?
I tried with latest package … the bug is still there.
I find out that :
-
just after creating the connection, the attribute isSecureConnection() returns false
-
after some time, the same attribute returns true !?!?!!
I suspect a bad thread synchronization …
The login fails while the isSecuredConnection return false,
The workaround is to wait for that attribute to get the correct value :
XMPPConnection connection = null;
try {
connection = new XMPPConnection(“localhost”);
while(!connection.isSecureConnection()) {
Thread.sleep(100);
}
connection.login(“admin”, “password”);
Chat newChat = connection.createChat(“phico@host”);
newChat.sendMessage(“hello”);
} catch (Exception e) {
e.printStackTrace();
} finally {
if (connection != null)
connection.close();
}
Hope the bug will be corrected in future releases …
.
I can’'t sleep at night because of this bug guys, please correct it.
How can we propose to use jivesoftware stuff in our mission critical apps if we can’‘t count on your dedication. I don’'t pretend bug free software, but I pretend bugs getting tackled as they come and not left dispart as in this case (and this is a serious infrastructure bug, not a fancy feature).
What’'s happening with this bug?
I fixed the same problem by switching from using this constructor:
XMPPConnection(String serviceName)
to this one:
XMPPConnection(String host, int port)
Looking up the service name via first constructor can take a number of seconds. With the second the DNS retrieval time is magnitudes quicker.
Which version of Smack and Wildfire are you using?
I was getting this error a while back and am not now although I may be using a modified PacketWriter in Smack, I would have to look back.
There were actually muliple causes for this bug, some in Smack some in Wildfire.
My last tests were pretty extensive in a heavily loaded test scenario.
They were all successful and I moved on.
skip
This bug is still not solved with the patch so I think I should mark this question as unanswered. The exception still arises at times.
Look earlier in this thread and you will see a
PacketReader.java attachment. My solution to this problem not yet in Smack_2.2.1 although developers may choose a different solution.
Rebuilding Smack with this file.
I have tested with this configuration extensively. I am now using Wildfire 3.0.1 which also fixed a concurrency problem which also caused this symptom.
The problem with this bug is there was more then one problem.
Skip
I would still prefer a official patched version. Having to mantain our own version of smack is a unnecessary burden.