[
https://issues.apache.org/jira/browse/AMQ-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated AMQ-5319:
------------------------------
Issue Type: New Feature (was: Bug)
> Message Redelivery Does Not Work As Expected With Concurrent Connections
> ------------------------------------------------------------------------
>
> Key: AMQ-5319
> URL: https://issues.apache.org/jira/browse/AMQ-5319
> Project: ActiveMQ
> Issue Type: New Feature
> Components: JMS client
> Affects Versions: 5.9.0
> Environment: All
> Reporter: Ulrich Romahn
> Priority: Minor
> Labels: client, redelivery, redeliveryPolicy
>
> The redelivery of messages does not work as expected when a message daemon is
> connected using multiple parallel connections.
> Consider the following scenario:
> 1. A message daemon is using Spring's
> org.springframework.jms.listener.DefaultMessageListenerContainer and
> configuring it with the following parameters:
> a: cacheLevel = CACHE_NONE
> b: concurrentConsumers = 5
> c: maxConcurrentConsumers = 5
> d: sessionTransacted = true
> 2. Furthermore, we are using the
> org.apache.activemq.pool.PooledConnectionFactory with the following
> configuration:
> a: createConnectionOnStartup = true
> b: maxConnections = 5
> We also setup a RedeliveryPolicy on the ConnectionFactory allowing messages
> to get re-delivered to the listener in case of an error.
> Once the DefaultMessageListenerContainer gets initialized by the Spring
> context, it will create 5 instances of a corresponding MessageListener
> implementation each getting its own exclusive connection pre-created and
> obtained from the ConnectionPool. Our message daemon is now connected to the
> broker using five concurrent connections.
> If one of the MessageListener has an error during processing of a message and
> throws an exception, the message gets put back onto the queue (on the client)
> and scheduled for re-delivery according to the policy. However, the same
> message is getting delivered to another listener using a different
> connection. Since the thread running the redelivery scheduler is bound to a
> connection, the second delivery is not delayed according to the redelivery
> policy. A likely failure in that listener will get the message put back onto
> the queue again and scheduled for re-delivery, but bound to that connection.
> Now, that same message will get delivered to yet another message listener
> without the defined delay. This will continue until the message got
> redelivered by each connection and will then be redelivered using a delay
> specified by the policy. In case the retry count is less than the number of
> connections, the message will get send to the DLQ.
> I observe the same behavior when using broker-side redelivery using the
> RedeliveryPlugin since there the delay is also bound to a connection.
> However, the re-delivery delay should be globally per message, regardless of
> session or connection. Although this is not a standardized feature, the
> current implementation is severely limited as described above which caused me
> to define this a bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
