I see someone else found the TLS plaintext error. I have seen it and other TLS packet corruption problems probably due to the same write concurrent problem developers have found. So far can not upgrade to 2.6.2 due to other problems. But I thought I share this anomaly I discovered in hope it too may find a fix someday.
In my case I developed a test application which logs in 150 users into 50 shared groups 3 to a group. This can be done as fast as the server will allow or with a time delay between login’s.
The application uses smack and simply does a new XMPPConnection followed by a login. Similar to the code snippet below:
XMPPConnection con = new XMPPConenction (“myserver”);
if (con. isConnected ())
{
System.out.println ("Login as user/password, Secure connect: " +
con.isSecureConnection() + " using TLS: " +
con.isUsingTLS () + “’’”);
con.login (“user”, “password”);
}
Most of the time all is good. isSecureConnection and isUsingTLS both are true. the subsequent login is successful. Occasionally (read rarely), under heavy server load either self inflicted (heavy usage) or other applications (more then likely causing the concurrent TLS server scenario to occur). isSecureConnection and isUsingTLS return false. The subsequent login throws an exception with a huge stack trace way down into the bowels of Sun socket code. Usually a read or write error. The exception appears to be in another thread and can’t be caught in my code. Which makes in impossible to initiate a recovery when it occurs.
Being an old school developer, I have a saying “if it can happen it will happen” therefore the error should be handled.
I have inserted a loop of up to thirty 100 ms waits, waiting for isUsingTLS == true, which seems to help most of the time. But that is pretty kludgey way to fix and if secure login is disabled always instigates a 3 second login delay.
I believe that the constructor should not return until a successful login can be preformed (e.g. TLS negotiation complete) or throw XMPPException is the connection cannot be established.
Is there a better way to handle this potential login failure?