[
https://issues.apache.org/jira/browse/CAMEL-26504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136798#comment-18136798
]
Claus Ibsen commented on CAMEL-26504:
-------------------------------------
PR https://github.com/apache/camel/pull/28985 now also stops transferring the
Netty transport headers with transferExchange=true. NettyPayloadHelper.getIn
and getOut marshal a copy without CamelNettyRemoteAddress,
CamelNettyLocalAddress, CamelNettySSLSession, CamelNettyChannelHandlerContext,
CamelNettyMessageEvent and CamelNettyChannel. Before, with
allowSerializedHeaders=true, the address headers (InetSocketAddress) were sent
and the default ObjectDecoder filter rejected them on the other side. Upgrade
guide updated.
_Claude Code on behalf of Claus Ibsen (davsclaus)_
> camel-netty / camel-netty-http - a reply that cannot be built or written
> leaves the client waiting, and the reply ignores allowSerializedHeaders
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26504
> URL: https://issues.apache.org/jira/browse/CAMEL-26504
> Project: Camel
> Issue Type: Bug
> Components: camel-netty, camel-netty-http
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Follow-up of CAMEL-26136 (PR #28914), which fixed the plain netty consumer
> hanging when no reply can be built.
> # camel-netty-http: when toNettyResponse throws in the consumer's reply
> handling, no response is written and the channel stays open, so the HTTP
> client hangs. It should answer with a 500 (or close the channel when nothing
> can be sent).
> # camel-netty: ServerResponseFutureListener only logs a reply write that
> failed. The channel stays open and the client may wait for a reply that never
> comes. Close the channel on a failed write.
> # camel-netty: with transferExchange=true, NettyPayloadHelper.getOut marshals
> the reply with DefaultExchangeHolder.marshal(exchange), not with
> allowSerializedHeaders as getIn does, so allowSerializedHeaders=true has no
> effect on the reply.
> _Claude Code on behalf of Claus Ibsen (davsclaus)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
