We are facing an intermittent issue with a Data Page that invokes a REST connector (GET API) after server restart. On the first invocation, the connector call consistently fails after ~30 seconds with java.net.SocketException: Socket closed. Tracer analysis shows that the execution is spending most of the time in D_TLSVersions before the connector activity fails at the configured timeout (30,000 ms). Interestingly, the API itself is healthy and returns valid data when retried — flushing the Data Page or re-triggering the call immediately results in successful execution with no changes to parameters or configuration. This behavior is observed only on the first call post restart (or initial interaction), and subsequent calls work fine. Based on this, we suspect the issue may be related to TLS/SSL handshake initialization, connection establishment, or transport-layer behavior during the first outbound HTTPS call rather than Data Page logic or API response handling. We would like to understand if this is a known behavior related to TLS setup (D_TLSVersions) or HTTP client connection pooling, and whether there are recommended configurations or patches to handle this initial handshake delay/failure in a more better way.
IS this consistent after every server restart? If so, what happens if you try to run this manually for the first time after every server restart?
Issue is occuring after every restart.
If we run the data page for the first time it is giving the exception, but it we flush the data page and retry - it starts working.