On our API Gateway 'mygw01' we have two services, A and B which expose very similar functions to our users. To minimise the amount of duplicated code, A and B transform their incoming requests into a standard format, which is then routed to service C, also on 'mygw01'.
A and B route to C via the standard "Route via HTTP to" assertion with the internal server name of the API gateway the address parameter: http://mygw01:8080/serviceC
We have recently had problems on our API Gateway with lots of connections stuck in a CLOSE_WAIT state, and have a suspicion that the fact that an invocation of A or B contributes to this problem by effectively using two sockets instead of one (one socket to handle the initial request, a second to handle the call to service C). A slight increase in the number of external calls, or the time taken by the backend to process the request seems to be enough to cause an often-fatal increase in the number of concurrent invocations which eventually block because, we assume, the Services A and B are waiting to call Service C, which is in turn unavailable because it too is waiting to get a socket to connect to our backend.
Assuming that this is contributing to our problems, is there a way to indicate to the API Gateway to not use a TCP Socket but rather simply to invoke Service C directly? I assume this is a good use case for a fragment, but we are probably a bit stuck for the time being.
Are there other approaches/modifications we can take to minimise the impact while we develop a more reliable solution?