[
https://issues.apache.org/jira/browse/AMQ-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093455#comment-14093455
]
Timothy Bish commented on AMQ-5319:
-----------------------------------
At most this would be a new feature request, however I recommend you take the
discussion to the user list as you might get additional input that could help
you solve your problem or find an alternative. We accept contributions so if
you would like to work on implementing the behaviour you think you need then
we'd be happy to review the code submission.
> 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)
