Using OS X, I found an issue in Java relating to SSL sockets. I don't know if your underlying connections are doing SSL or not, but the file handles for the socket are not being released always. As a result, the max open file limit is reached, which blocks sockets from being created too. (A socket is still a file handle to the OS.)
This is a bug in the JVM...and it seems that the issue exists at least on Linux and OS X. I found others with the same issue.
Possibly another process monitoring tool will give you more info about the running JVM process to see what open file handles it has?
when generating the SSLSocket from the Socket in the call to SSLFactory.createSocket, setting the autoClose to false lets me close the SSL socket, and resume using the original socket once again.
The goal is to take an existing SSL connection that has already passed sensitive information through encrypted, and switch back to using the socket decrypted. This is specifically important for FTP and NAT routers.
I am fairly sure this is possible...but I haven't figured out the trick to do so.
The socket was connected in the clear, no encryption. The command was sent to the server telling to switch to encryption. This is where SSLSocketFactory comes in and takes the socket and returns a SSLSocket. The issue is later we want to disable encryptions...but can't. I still have an original reference to the decrypted Socket...but its input/outputstreams have been taken over.
I even tried a proxy socket with two threads that were reading and writing data from the socket tot he proxy socket, but then the encryption didn't work I assume because I was a man int he middle.
How can you degrade a SSLSocket back to using no encryption...just the raw input/output streams?
(The reference for this in FTP is the command CCC.)