pegarules.pub.services.ConnectorException: Caught unhandled exception: java.net.SocketTimeoutException: Read timed out

General
, , , , ,
1

I have configured Connect-Rest rule and it is working in out DEV and QA environment. But the same configurations are not working on the Staging environment and giving the read time out always. I am able to hit the api using the postman successfully.

can you suggest me the steps i can perform to understand the issue better.

below is the snip when I am doing the test connection.

TestConnectionError.PNG
TestConnectionError.PNG1515×379 23.1 KB

2

@MandeepRawat did you go through the following troubleshooting article?

What connect timeout errors do you see in the logs?

See recommendations from the above articles:

Recommendations

Perform the following actions:

  • Evaluate individual instances of the time-out by performing the following actions:
    • Assess whether the failures are sporadic or whether the external application is unavailable.
    • Assess whether the issue is local to a single node or whether it affects all users, services, and batch processes.
  • Contact the owners of the external application, and network and data center staff, as appropriate, to address the issue.

This PCC post Socket timeout error on Connect REST also has some tips., as does this post. Some suggestions relating to proxy config.

The official troubleshooting documentation for later releases can be found here.

3

Hi @MarijeSchillern

thanks for the reply , I have gone through the said links but unfortunately that did not helped much.

my other connect-rest are working fine

also I performed the CURL command from the server where pega is hosted and I was successfully getting the response.

Do you have any idea on how can find out if the request is not going from Pega to the external system or the external system is not sending us the response ?

any tools or approach would be much appreciated.

4

@MandeepRawat if your issue is not yet resolved I would suggest that you log a support Incident for this which will allow our support team to analyze your configuration and any errors in the network logs.

If you do chose to go down this route could I ask that you provide us with the INC number so that we can help you track the issue and hopefully the final solution?

5

@MarijeSchillern thanks for your help. We found out that there were some JVM parameter set for a particular instance which was causing this issue. We have handled this issue by modifying the JVM parameters as per our needs.