You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Jean-Baptiste Nizet (JIRA)" <ji...@apache.org> on 2019/04/12 08:53:00 UTC

[jira] [Created] (ARTEMIS-2304) Message are lost when using (default) auto-delete-queues/auto-delete-addresses

Jean-Baptiste Nizet created ARTEMIS-2304:
--------------------------------------------

             Summary: Message are lost when using (default) auto-delete-queues/auto-delete-addresses 
                 Key: ARTEMIS-2304
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2304
             Project: ActiveMQ Artemis
          Issue Type: Improvement
          Components: Broker
    Affects Versions: 2.7.0
            Reporter: Jean-Baptiste Nizet


Hi.

I've been searching for quite a time before finally finding a workaround for the following issue, and I think this should be fixed or the documentation should at least be improved.

 

Steps:
 * install artemis
 * create a new broker, using artemis create (using the default options)
 * run the broker
 * create a simple spring boot app using the narayana transaction manager and the official spring boot artemis starter. The application contains a transactional REST service which sends a message using JMS, and a transactional listener that is supposed to be notified when a message is sent

Everything runs fine: the address and the queue are auto-created, the message is sent, and is immediately delivered to the listener.

BUT, if I introduce an artificial delay of, for example, 100 milliseconds after the message is sent (thus delaying the XA transaction commit of 100 milliseconds, simulating additional work being done in the transaction), then
 * the listener never receives the message
 * when looking at the web console, the message never appears in the queue, or in the expiry queue, or in the DLQ

If I add
{noformat}
<auto-delete-addresses>false</auto-delete-addresses>
<auto-delete-queues>false</auto-delete-queues>
{noformat}
to the address settings, then it all works fine.

So I guess there is some kind of race condition where the listener or the sender somehow creates the queue when sending/reading the first message, but the queue is then deleted while the transaction is still in progress, and the listener thus never receives it.

Note that this all happens without any exception being thrown anywhere. The message is just lost.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)