[CAMEL-19097] Using Camel as a REST client towards a REST service hosted by JBoss EAP 7.4 leads to connections in TCP/IP state CLOSE_WAIT on the server side.

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Information Provided
• Affects Version/s: 2.25.3
• Component/s: camel-http, camel-netty4-http
• Estimated Complexity: Unknown
• Assignee: Unassigned
• Reporter: Philipp Bachmann
• Created: 27/Feb/23 19:15
• Updated: 27/Feb/23 19:36
• Resolved: 27/Feb/23 19:36

Description

Even though a similar / identical phenomenon has popped up both on [e-mail] and at <https://stackoverflow.com/questions/53258874/http-and-https-connections-are-kept-in-close-wait-if-using-apache-camel>, I could not find a solution so far.

To my understanding Camel as a REST client closes the connection, that's why the server's TCP/IP state switches to CLOSE_WAIT, but it should do so only temporarily until the server code also closes the respective connection. This, however, does not seem to happen, leaving its end of the connection in CLOSE_WAIT state "forever."

We triggered the very same REST service using SoapUI as a REST client. In this case, the server correctly closes its end of the TCP/IP connection.

So the Camel implementation seems to somehow contribute to this behavior of JBoss EAP, even though I'd still say that JBoss should reliably end its connection if the client already did so regardless of the details exchanged via this connection before, i. e. regardless of whether SoapUI or Camel was the client.

So: 1) Are there known workarounds / additional URL endpoint parameters to set on the Camel side to avoid this behavior?

2) To further analyze what's really going on here it might prove useful to route the REST connection via a web proxy like mitmproxy. How can I do this with the least possible modifications to the respective Camel endpoint definition?