We have a product which uses OpenSSL to connect and transfer application level data. There are two ways to connect, and get the application level data from Agent to Client

  1. Client (C/C++/OpenSSL) -> Agent (C/C++/OpenSSL)
  2. Client (C/C++/OpenSSL) -> Proxy Server (Java) -> Agent (C/C++/OpenSSL)

Client and Agent are implemented in C, while Proxy Server uses Java code with BufferedInputStream and BufferedOutputStream. The issue is, connecting Client to Agent is very fast (that is relatively). While connecting Client to Proxy Server is very slow - that is orders of magnitudes slow.

I analyzed the code, and found that first read or write in the Java code gets blocked and most of the time is taken while doing that. Subsequent read or write of application data takes little time. To further debug the issue I put in place explicit SSLSocket::startHandshake() call. What I observed is that this handshake is blocking and consuming most of the time. I understand that this is a blocking call, and BufferedInputStream is also stuck on the same thing first time around, but what I can't understand is why it is taking so long.

FYI, it takes anywhere between 2 to 11 seconds for startHandshake to complete. IMO this is not acceptable, given that subsequent processing including all the application data transfer doesn't take more than fraction of a second to complete. And just to be clear all the above boxes are on the same network, so it is not a network latency issue IMO.

Can somebody kindly suggest what might be wrong or what can be done to fix this?