[
https://issues.apache.org/jira/browse/CAMEL-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16718.
---------------------------------
Resolution: Fixed
> 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.7.5, 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)
