Ulrich Romahn created AMQ-5319:
----------------------------------
Summary: 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: Bug
Components: JMS client
Affects Versions: 5.9.0
Environment: All
Reporter: Ulrich Romahn
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)
