[
https://issues.apache.org/jira/browse/CAMEL-16227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285793#comment-17285793
]
Krzysztof Jamróz commented on CAMEL-16227:
------------------------------------------
The underlying issue is that each {{NettyProducer}} (there are 2 of them - one
for each {{to("netty:tcp...")}}) has its own
{{NettyCamelStateCorrelationManager}}, each with separate map of
{{NettyCamelState}}. And when netty is invoked second time, what is supposed to
reuse channel, it really reuses it but registers callback in wrong correlation
manager. {{NettyCamelState}} should be registered in correlation manager for
producer that opened the channel but uses correlation manager of sending
producer. Then, when response is processed first {{NettyCamelState}} is found,
not the second one.
I am not sure how this should be a fixed:
# Looking up correct correlation manager in {{processWithConnectedChannel}}
would need some information which currently is not there, eg. new property on
Exchange with correlation manager or original producer similar to
{{NETTY_CHANNEL}}
# Moving {{NettyCamelStateCorrelationManager}} from {{NettyProducer}} to
{{NettyEndpoint}} seems to be risky or wrong
# There is no room to store additional data in {{Channel}} itself
# Reusing the same {{NettyProducer}} when {{reuseChannel=true}} is probably
wrong, because each endpoint can have slightly different configuration
# Something different?
> Netty with reuseChannel=true invokes wrong callback
> ---------------------------------------------------
>
> Key: CAMEL-16227
> URL: https://issues.apache.org/jira/browse/CAMEL-16227
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
> Affects Versions: 3.7.2
> Reporter: Krzysztof Jamróz
> Priority: Major
> Attachments: NettyReuseChannelCallbackTest.java
>
>
> Netty when configured with {{reuseChannel=true}} invokes wrong
> {{AsyncCallback}}. It invokes callback registered by first netty invocation
> in given route multiple times. This can be observed by debugging
> {{NettyReuseChannelTest}}. This seems not to cause serious problems at least
> in simple cases, because both callbacks (from {{SendProcessor}}) do not do
> much and simply continue routing. I am not sure if in more complex cases this
> could cause more problems.
> However there is one observable issue caused by this behavior: event
> notifications contain wrong endpoint and wrong time taken. I attached a test
> for it.
> Another problem is that this behavior makes it harder (if possible at all) to
> fix CAMEL-16178 for case with {{reuseChannel=true}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
