[
https://issues.apache.org/jira/browse/CAMEL-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362957#comment-17362957
]
Morgan L edited comment on CAMEL-16718 at 6/14/21, 1:27 PM:
------------------------------------------------------------
This issue does not occur when using the Mina TCP producer, nor when using the
camel-hystrix circuit breaker implementation.
was (Author: morgan l):
This issue does not occur when using the MINA tcp producer, nor when using the
camel-hystrix circuit breaker implementation.
> 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
> Priority: Major
> Attachments: 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)
