[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7500: --- Fix Version/s: (was: Future) 2.16.0 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 Assignee: Claus Ibsen Fix For: 2.16.0 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.3.4#6332)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CAMEL-7500: Fix Version/s: Future 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 Assignee: Willem Jiang Fix For: Future 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)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ 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)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Attachment: NettyRedeliveryTest.java 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)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Attachment: (was: NettyRedeliveryTest.java) 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)
