activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ulrich Romahn (JIRA)" <>
Subject [jira] [Reopened] (AMQ-5319) Message Redelivery Does Not Work As Expected With Concurrent Connections
Date Mon, 11 Aug 2014 22:16:12 GMT


Ulrich Romahn reopened AMQ-5319:

I disagree with this!
"This sort of thing" is neither a question nor a discussion but a statement of facts. And
in my statement I assert that I consider this behavior a bug.
If you believe that this is not a bug or should be re-categorized as a feature request please
state it as such.
But simply dismissing my report as "this sort of thing" is almost insulting!

> Message Redelivery Does Not Work As Expected With Concurrent Connections
> ------------------------------------------------------------------------
>                 Key: AMQ-5319
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.9.0
>         Environment: All
>            Reporter: Ulrich Romahn
>              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

View raw message