[
https://issues.apache.org/jira/browse/CAMEL-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13817231#comment-13817231
]
Claus Ibsen edited comment on CAMEL-6945 at 11/8/13 12:40 PM:
--------------------------------------------------------------
I think we have a catch-22 situation here.
Yeah this ticket about the netty http producer should close the connection if
"Connection: close" is in the HTTP header, then that is correct. The missing
piece was that the check was already there, but the binding code didn't set the
Exhcange.CLOSE header. Though this code sets it as a property on the exchange.
Should really be header instead to be consistent.
Okay the catch-22 is when you bridge using netty-http, eg
{code}
1..n clients
-->
from netty-http
to netty-http
-->
backend server
{code}
Then you have N+ clients on the outside that may have "Connection: close" in
their http headers. So on the Camel server we have the catch-22 situation,
because
1. We want the netty http consumer to close the connection when the request is
done (current code does that)
2. We most likely do not want to close connections between Camel and the
backend server (to keep these connections alive and fast as possible)
So we should have a better way of doing #2 to tell Camel it should disregard
the "Connection: close" header but keep it alive between Camel and backend
server. eg some way of configuring this better.
Today we have the disconnect option people could use to force this
{code}
from netty-http
to netty-http?disconnect=false
{code}
But I am not sure if setting that disconnect option would have the http header
override it, so if there is a http header with "Connection: close" it may take
precedence and still close the connection on the netty http producer side.
was (Author: davsclaus):
I think we have a catch-22 situation here.
Yeah this ticket about the netty http producer should close the connection if
"Connection: close" is in the HTTP header, then that is correct. The missing
piece was that the check was already there, but the binding code didn't set the
Exhcange.CLOSE header. Though this code sets it as a property on the exchange.
Should really be header instead to be consistent.
Okay the catch-22 is when you bridge using netty-http, eg
{code}
1..n clients
-->
from netty-http
to netty-http
-->
backend server
{code}
Then you have N+ clients on the outside that may have "Connection: close" in
their http headers. So on the Camel server we have the catch-22 situation,
because
1. We want the netty http consumer to close the connection when the request is
done (current code does that)
2. We most likely do not want to close connections between Camel and the
backend server (to keep these connections alive and fast as possible)
So we should have a better way of doing #2 to tell Camel it should disregard
the "Connection: close" header but keep it alive between Camel and backend
server. eg some way of configuring this better.
Today we have the disconnect option people could use to force this
{code}
from netty-http
to netty-http?disconnect=true
{code}
> camel-netty-http producer should close the connection when the request
> connection header is close
> -------------------------------------------------------------------------------------------------
>
> Key: CAMEL-6945
> URL: https://issues.apache.org/jira/browse/CAMEL-6945
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
> Affects Versions: 2.12.0, 2.12.1
> Reporter: Willem Jiang
> Assignee: Willem Jiang
> Fix For: 2.12.2, 2.13.0
>
>
> camel-netty-http producer should close the connection when the request
> connection header is close otherwise it will get ClosedChannelException when
> the producer try to reuse the connection.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
