[
https://issues.apache.org/jira/browse/CAMEL-26182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136881#comment-18136881
]
Claus Ibsen commented on CAMEL-26182:
-------------------------------------
PR: https://github.com/apache/camel/pull/29010
1-3 are fixed: the sync=false producer keeps the message, the consumer replies
only with sync=true, and a textline consumer converts the reply to a String.
The consumer now also honours disconnectOnNoReply and noReplyLogLevel.
4 is the allow-list of the MINA object codec: it only deserializes the classes
of objectCodecPattern (empty by default; a String has no class descriptor so it
passes). A rejected array makes ObjectInputStream fail with "invalid type
code". objectCodecPattern=[B on the producer makes the byte[] reply work.
Documented, the default is not widened.
_Claude Code on behalf of Claus Ibsen (davsclaus)_
> camel-mina - with sync=false an InOut producer loses the body and headers,
> and the consumer writes a reply even with sync=false
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26182
> URL: https://issues.apache.org/jira/browse/CAMEL-26182
> Project: Camel
> Issue Type: Bug
> Components: camel-mina
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Found while adding the catalog body types of mina (CAMEL-24961, PR #28413).
> h4. 1. With sync=false and InOut, the body and headers are lost after the
> producer
> {{MinaProducer.process}} (main 2a465aa4814c, line 121) always calls
> {{maybeDisconnectOnDone}}, which at line 215 calls {{exchange.getOut()}} when
> the exchange is out capable. With {{sync=false}} no reply is set, so this
> creates an empty out message: after the producer the body is null and the
> headers are gone. Checked on 4.24.0-SNAPSHOT with local mina TCP sockets, an
> InOut exchange sent to {{mina:tcp://localhost:port?sync=false}}.
> Proposed: read the header with {{exchange.getMessage()}} (or only look at the
> out message when {{exchange.hasOut()}}).
> h4. 2. The consumer ignores sync=false and always writes the body back
> {{MinaConsumer.ReceiveHandler.messageReceived}} (line 476 to 478) writes the
> response (the out or in body) to the session whenever it is not null; it
> never looks at {{sync}}. With {{sync=false}} (TCP and UDP) the client gets
> the request body echoed back. Checked on 4.24.0-SNAPSHOT with local mina TCP
> and UDP sockets.
> Proposed: write a reply only when {{sync=true}}.
> h4. 3. The textline consumer writes a byte[] or stream reply as its toString
> The producer converts the body to a String for {{textline=true}}
> ({{MinaProducer}} line 146 to 148), but the consumer passes the reply as is
> to {{MinaHelper.writeBody}} ({{MinaConsumer}} line 478), and the MINA
> {{TextLineEncoder}} calls {{toString()}}: a byte[] reply arrives as
> {{\[B@...}}, a stream reply as the class name of the stream. Checked on
> 4.24.0-SNAPSHOT with a textline consumer whose route sets a byte[] body.
> Proposed: convert the reply to a String in the consumer when textline is set,
> as the producer does.
> h4. 4. A byte[] reply fails to decode under the default object codec
> With the default object serialization codec, a consumer whose route replies
> with a byte[] ({{MinaHelper.writeBody}}, line 50 to 63, writes it as is)
> makes the producer fail to decode the reply with "invalid type code: 62".
> Only a String passes both ways without {{objectCodecPattern}}. Checked on
> 4.24.0-SNAPSHOT with local mina TCP sockets, default codec, a route that sets
> a byte[] reply.
> Proposed: find out why the byte[] does not round-trip in the object codec and
> fix it, or document that the reply must be a String or a class allowed by
> objectCodecPattern.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
