Philipp Bachmann created CAMEL-19097:
----------------------------------------
Summary: 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.
Key: CAMEL-19097
URL: https://issues.apache.org/jira/browse/CAMEL-19097
Project: Camel
Issue Type: New Feature
Components: camel-http, camel-netty4-http
Affects Versions: 2.25.3
Reporter: Philipp Bachmann
Even though a similar / identical phenomenon has popped up both on
[[email protected]|mailto:[email protected]] 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?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
