[
https://issues.apache.org/jira/browse/CAMEL-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363751#comment-17363751
]
Morgan L edited comment on CAMEL-16718 at 6/15/21, 8:13 PM:
------------------------------------------------------------
To give you more information about the write error which can lead to this,
debugging indicates that an error in
{{io.netty.channel.AbstractChannel.writeAndFlush}} (or a subclass
implementation) which leads to an invocation of
{{io.netty.channel.AbstractChannel.handleWriteError}} leads to this bug
occuring.
I was able to identify a possible partial cause of the issue, located in
{{org.apache.camel.component.netty.NettyProducer.processWithConnectedChannel}}.
An anonymous subclass of ChannelFutureListener is created with a callback that
invokes {{producerCallback.done}} if and only if the associated ChannelFuture
completed successfully. If it failed, {{producerCallback.done}} is not invoked.
In a debugger, manually invoking {{producerCallback.done}} inside that callback
will prevent the route from hanging.
A comment in that method states that {{exceptionCaught}} should be invoked to
handle failure instead, but {{exceptionCaught}} is never invoked in this case.
This is about as far as I got.
As for difficulty reproducing this, can you check in your debugger whether
{{AbstractChannel.handleWriteError}} is being invoked?
edit: also, are you using an IDE or any tool to run these? I am using
IntelliJ. If you tell me what tool you're using, I will see if I can reproduce
it on that.
was (Author: morgan l):
To give you more information about the write error which can lead to this,
debugging indicates that an error in
{{io.netty.channel.AbstractChannel.writeAndFlush}} (or a subclass
implementation) which leads to an invocation of
{{io.netty.channel.AbstractChannel.handleWriteError}} leads to this bug
occuring.
I was able to identify a possible partial cause of the issue, located in
{{org.apache.camel.component.netty.NettyProducer.processWithConnectedChannel}}.
An anonymous subclass of ChannelFutureListener is created with a callback that
invokes {{producerCallback.done}} if and only if the associated ChannelFuture
completed successfully. If it failed, {{producerCallback.done}} is not invoked.
In a debugger, manually invoking {{producerCallback.done}} inside that callback
will prevent the route from hanging.
This is about as far as I got.
As for difficulty reproducing this, can you check in your debugger whether
{{AbstractChannel.handleWriteError}} is being invoked?
edit: also, are you using an IDE or any tool to run these? I am using
IntelliJ. If you tell me what tool you're using, I will see if I can reproduce
it on that.
> Conflict with Netty TCP + Resilience4J circuit breaker
> ------------------------------------------------------
>
> Key: CAMEL-16718
> URL: https://issues.apache.org/jira/browse/CAMEL-16718
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
> Affects Versions: 3.7.4, 3.10.0
> Reporter: Morgan L
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 3.11.0
>
> Attachments: sample-camel - broketcpserver.log.txt, sample-camel -
> nettytest.log.txt, sample-camel.zip
>
>
> My team has found what we believe is a conflict between the Netty TCP
> producer and the Resilience4J circuit breaker, under specific circumstances.
> When the Netty TCP client encounters an error while writing to the server
> (for us, usually a broken pipe exception), if it is inside a circuit breaker,
> the route will hang indefinitely.
> Discussion on Zulip: [Conflict with Netty TCP + Resilience4J circuit
> breaker|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Conflict.20with.20Netty.20TCP.20.2B.20Resilience4J.20circuit.20breaker]
> A zipped version of the complete test project is attached. It should allow
> you to reproduce the issue.
> By running BrokeTCPServer.main(), and then invoking
> NettyTest.testNettyCircuitBreaker(), you should see that of the two messages
> we push into the queue, only one is processed. Only one connection is
> initiated to the BrokeTCPServer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
