[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Browning updated CAMEL-7500: -------------------------------- Summary: Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages (was: Concurrent modification of exchange during retry leads to futher processing of failed messages) > Concurrent modification of exchange during retry after netty TCP failure > leads to futher processing of failed messages > ---------------------------------------------------------------------------------------------------------------------- > > Key: CAMEL-7500 > URL: https://issues.apache.org/jira/browse/CAMEL-7500 > Project: Camel > Issue Type: Bug > Components: camel-netty > Affects Versions: 2.13.1 > Reporter: Bob Browning > Attachments: NettyRedeliveryTest.java > > > When a exception occurs on a netty TCP channel such as ChanelClosedException > then there are two invocations of the producer callback. > If there is a redelivery handler configured this causes either two threads to > be added to the scheduled thread-pool which then compete or in the more > common case the first invocation adds the redelivery thread but in doing so > clears the exception from the exchange such that when the subsequent callback > invocation occurs it see's the event as a success and continues routing of > the exchange. > Note this also seems to be a cause of negative inflight messages on the route. > The first callback invocation occurs in the ChannelFutureListener which is > the usual case. > The second callback invocation which comes from the ClientChannelHandler > registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)