I am experiencing the bug as described by Kevin with Wildfire. I have found that waiting about 10-20 minutes will bring back Gaim after such a freeze (I'm guessing the operating system detected that the socket was idle and dropped it, or something along those lines). At the bottom there is a patch for Gaim that sets the socket timeout for closing the connection to 3 seconds. I am using Gaim 1.5.0 (latest update for Dapper) with Wildfire 3.0.0.
Here's a Debian bug filed about the same issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375317 Here's the research I have done on this issue: The SSL connection close in Wildfire (source for version 3.0.0) happens at org.jivesoftware.wildfire.net.TLSWrapper.java:188. It performs SSLEngine.closeOutBound() I also found this: "To close the connection the user must first inform the SSLEngine that there is no more application data to be sent and, therefore, the session should be terminated. This is done by calling SSLEngine.closeOutbound(). After this, a call to wrap() will generate a close message that must be sent to the other peer. A well-behaved program should wait for the answer to this message, but the SSL/TLS specification says that it is acceptable to close the socket after sending the initial close message. And, typically, this is the easiest solution. After being closed, an SSLEngine cannot be reused." The above is from: http://www.onjava.com/pub/a/onjava/2004/11/03/ssl-nio.html To me it sounds like Gaim is demanding that the close message be received. I don't know any details about the specification, but if it is optional then Gaim should not freeze the entire application while waiting for the message. -- gaim hangs due to gnutls, switch to nss https://launchpad.net/bugs/18524 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
