We have a couple of issues concerning the behavior of the XMPPConnection constructor (which also affect the SSLXMPPConnection constructor). The problem we are dealing with is that on several of our systems it takes a long time to establish the socket connection back to the XMPP server, and establishing the connection is not generally successful. In trying to establish the connection, the following exception is thrown (Smack 1.3.0):
Connection failed. No response from server.:
The first issue that we have encountered is that in the PacketReader.startup() method, the timeout is hard-wired to 5000 ms. This appears to be the case in both 1.3.0 and 1.4.0.
The second issue that we have encountered is that the XMPPConnection.init() method, which is called by the constructor, constructs both the PacketReader and PacketWriter objects which in turn start 2 threads (one for each) running. There is no issue with constructing the objects and starting the threads unless the exception noted above is thrown. In that case, both of the threads are left hanging around since the shutdown() methods are not called in the event of an exception.
These issues are amplified when our application employs its retry logic in the event of a connection failure. For each retry that occurs, the threads are left hanging around. In the case of a memory constrained JVM, this will eventually cause an out of memory condition in the JVM.
Is there a way to do the following?
Make the startup timeout configurable, as in possibly using the packet reply timeout or a new timeout value. I noticed a post from Nov 3, 2003 (Re: Login Timouts - setTimeout(int millisec)) that indicated this might be dealt with in the next release, but I didn’'t see anything in 1.4.0 regarding it.
In the event of a connection failure, cleaning up any resources that were allocated - shutting down the reader/writer threads, etc.
Perhaps I’'ve misinterpreted the behavior of the constructor, etc. If so, let me know.