Solutions

502 Bad Gateway or SocketTimeoutException when using IG (All versions)

Last updated Aug 10, 2020

The purpose of this article is to provide assistance if you encounter a 502 Bad Gateway response when routing from IG to a custom endpoint, or an endpoint in IDM or AM using a ClientHandler. This response is accompanied by a "java.net.SocketTimeoutException: null" error.

1 reader recommends this article

Symptoms

An error similar to one of the following is shown in the web application container log (for example, catalina.out for Apache Tomcat™) when the endpoint is called from IG (this may be an intermittent error):

--- (response) id:aa167dcf-461d-513b-a942-9272bad726fb-736 ---

HTTP/1.1 502 Bad Gateway
Context's content :
attributes:
     org.apache.tomcat.util.net.secure_protocol_version: "TLSv1.2"

[I/O dispatcher 11] INFO mo.f.o.d.t.T.timer.top-level-handler - Elapsed time: 10025 ms 
[I/O dispatcher 11] WARN mo.f.o.f.LogAttachedExceptionFilter - Response [Status: 502 Bad Gateway] to 'https://idm.example.com:8444/openidm/endpoint/test' carries an exception [txId:aa167dcf-503b-461d-a745-9285bad726fb-735] 
java.net.SocketTimeoutException: null    
   at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.timeout(HttpAsyncRequestExecutor.java:375)
[http-bio-198.51.100.0-8443-exec-2] ERROR mo.f.o.handler.router.RouterHandler - no handler to dispatch to 
[http-bio-198.51.100.0-8443-exec-1] INFO mo.f.o.d.c.C.c.myClientHandler

--- (response) id:aa167dcf-461d-513b-a942-9272bad726fb-736 ---

HTTP/1.1 502 Bad Gateway 
Context's content : 
attributes: 
     org.apache.tomcat.util.net.secure_protocol_version: "TLSv1.2"

[I/O dispatcher 12] WARN o.f.openig.handler.ClientHandler - An error occurred while processing the request 
java.net.SocketTimeoutException: null 
   at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.timeout(HttpAsyncRequestExecutor.java:375) 
[I/O dispatcher 12] INFO o.f.o.d.c.C.c.TlsClientHandler -

Recent Changes

N/A

Causes

The connection from IG to the backend is timing out before a response has been received by the client application. By default, the timeouts for the IG ClientHandler are set to 10 seconds.

Solution

This issue can be resolved by increasing the timeouts (connectionTimeout and soTimeout) for the ClientHandler in the IG route. For example, the configuration in the route would look similar to this with a 30 second timeout:

 "handler": { 
   "name": "myClientHandler", 
   "type": "ClientHandler", 
   "config": {
      "connectionTimeout": "30 seconds", 
      "soTimeout": "30 seconds" 
   }
}

Global timeouts

If you prefer to set these timeouts globally in config.json (located in the $HOME/.openig/config/ directory), you should:

Update the timeouts for the ClientHandler in the heap in config.json, for example:

{
"handler": {
"type": "Router", "name": "_router"
},
"heap": [
 {
   "name": "myClientHandler", 
   "type": "ClientHandler", 
      "config": {
         "connectionTimeout": "30 seconds", 
         "soTimeout": "30 seconds" 
      }
  }
  ]
}

Define the ClientHandler correctly in the route to use this global configuration, for example:
```
"handler": "myClientHandler",
```

See Configuration Reference › Route and Configuration Reference › Router for further information.

Related Training

N/A

Related Issue Tracker IDs

N/A