Hi Todd,
You've done you're homework.
As you see in JBREM-1307, there is a bug in Java's SSLSocket that can cause a deadlock, and the suggested workaround (I haven't tried it) is to turn on socket.check_connection. As for your concerns about doing that:
* results in an extra round-trip I/O (not good for a variety of reasons - throughput, remote clients with high latency connecitons, etc.).
This is true.
* potential to hit other problems with check_connections enabled. e.g. found this: https://community.jboss.org/message/369442
Note that the problem in https://community.jboss.org/message/369442#369442 is based on a failure to set Remoting's socket timeout parameter. I don't think it's really a deadlock. The default client side timeout in Remoting is 30 minutes, so it just looks like a deadlock. I'm not aware of any problems with the connect timeout. If you're looking at the code, the connect timeout is enforced in org.jboss.remoting.transport.socket.SocketClientInvoker.connect().
Hope that helps.
-Ron