How do i figure out why and where is the connectivity problem?

There is a website www.example.com

It hits an API.

Say its URL is www.example.com/backend/v1/path/to/what/i/want

Now, in turn this URL calls another api.

https://www.universalapi.com

Many clients use the same api, that is why it's called universalapi.

For example, example2.com will also call the same API after getting redirected from its backend like what happened above.

The response from the server is coming very slow and sometimes don't even come. As per the logs the response seems to come from universalapi.com.

2024-02-14 13:17:58 [blablathread] ERROR a.b.c.d.e.RestNxTemplate:81 - Error response : I/O error on POST request for "https://universalapi.com/this/is/what/i/want": Read timed out; nested exception is javax.net.ssl.SSLException: Read timed out
2024-02-14 13:17:58 [blablathread] ERROR a.b.c.d.e.RestNxTemplate:83 - Error log :
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://universalapi.com/this/is/what/i/want": Read timed out; nested exception is javax.net.ssl.SSLException: Read timed out

Sometimes it also gives the correct response which is the data from the api. But sometimes it is slow and that's what I need to investigate along with why I am getting read timeout, where's the actual problem?

The thing is universalapi is being hit by various clients as stated earlier and all of them are able to display the output.
It suggests the server example.com is not able to handle the request. But any ways to actually prove this?

Load testing comes to my mind. Not sure how I'd be able to do that though as I don't have QA expertise.

How'd you tune this server?

I tried to

  1. Send a curl POST Request to universalapi as normal curl wasn't accepted.

curl: (35) TCP connection reset by peer

  1. ping universalapi
    ping gave the ip but it is not pingable. Most likely the ping is disabled on the remote server.

  2. telnet is working in that IP at port 443, but that doesn't give the variable of interest for me. Which is the time required to get response from the server. As I am trying to figure that out.

Do you have the stack trace on the server side that you could share? Is the API on the wire or being fronted by a proxy like haproxy, F5, Netscaler, etc.?

1 Like

This issue is resolved. As always, FIREWALL policy that was blocking traffic after a certain time durations or some random policy. I troubleshooted it after I tried to call internal API (it succeeded) whereas calling external APIs failed, that was the entire issue.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.