activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Harvey <Brad.Har...@gbst.com>
Subject RE: artemis auto queue deletion results in lost messages
Date Thu, 15 Oct 2020 05:56:44 GMT
Hi Domenico,

Thanks for your response.  I’m aware that the feature can be turned off, but it was only
because we stumbled into the problem that we knew to do this - I hope that by reporting this
it can be fixed so that others don't experience the same problem.  Right now, it is a massive
trap for new players especially since it is enabled by default.

By putting some pauses in the test and watching the addresses/queues in the web console, I
see that both the address and queue are deleted at step 3:
#3 Disconnect the consumer - queue now has no consumers and no messages, but the producer
is still connected to the address.

My feeling is that either:
1. auto create should kick in to create the address and queue again at step 4, or
2. they should not be deleted while the producer is still connected to the address

Either of these would ensure that the message in step 4 is delivered to a queue and can be
subsequently received by the consumer in step 5.

Additional observations:
* The test case does pass against activemq classic (if deleting inactive destinations is enabled
as per  https://activemq.apache.org/delete-inactive-destinations.html).
* Enabling <send-to-dla-on-no-route>true</send-to-dla-on-no-route> does not seem
to result in the message at step 4 being sent to the DLA - I guess because the address isn't
there.

Regards
Brad.

-----Original Message-----
From: Domenico Francesco Bruscino <bruscinodf@gmail.com>
Sent: Tuesday, 13 October 2020 6:25 PM
To: users@activemq.apache.org
Subject: Re: artemis auto queue deletion results in lost messages

Hi Brad,

it looks like the expected behaviour of the auto-delete-queues feature to me.
If you need to change the default auto-delete-queue setting[1] you could set it to false for
the default or other matches, ie for the default match:

<address-setting match="#">
  <auto-delete-queues>false</auto-delete-queues>
  ...

Moreover there are two options to customize the behaviour of the auto-delete-queues feature:
auto-delete-queues-delay[1] and auto-delete-queues-message-count[1].

[1]
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2Flatest%2Faddress-model.html%23configuring-addresses-and-queues-via-address-settings&amp;data=02%7C01%7CBrad.Harvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&amp;sdata=qmrFFt%2ByFp9OjDRSXnllHMpkuwAyIBfdnPge%2Ben9uGQ%3D&amp;reserved=0

Regards,
Domenico

Il giorno mar 13 ott 2020 alle ore 07:21 Brad Harvey <Brad.Harvey@gbst.com> ha scritto:

> Hi,
>
> When auto queue deletion is enabled (which is the default setting!) it
> is easy to lose messages.
>
> Pre-req: Create a new artemis 2.15.0 broker with default settings.
>
> #1 Connect a producer and consumer to a queue - address & queue will
> be auto created.
> #2 Send a message from producer and receive it from consumer - works fine.
> #3 Disconnect the consumer - queue now has no consumers and no
> messages, but the producer is still connected to the address.
> #4 Send another message from the producer.
> #5 Connect another consumer and try to receive the message from the queue.
>
> Expected: Message can be consumed from the queue.
> Actual: This will fail as there is no message on the queue to receive.
> There are no errors returned to the sender, nothing in the broker
> error logs, nothing in the DLQ.  The message is lost.
>
> Workaround is to disable auto queue deletion in the broker address
> settings.
> <auto-delete-queues>false</auto-delete-queues>
>
> Related is
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissu
> es.apache.org%2Fjira%2Fbrowse%2FARTEMIS-2304&amp;data=02%7C01%7CBrad.H
> arvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&amp;sdata=sV2Ww7KhBvNfcpJLMb0h02fJXG8uV1usSUr1NLKgp%2Fw%3D&amp;reserved=0
which shows a different set of steps to lose a message when using auto queue delete.  I have
verified it still fails on 2.15.0 using the reproducer supplied ( https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjnizet%2Fartemisissue&amp;data=02%7C01%7CBrad.Harvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&amp;sdata=OdRQPXwGLF1TXyiUFRN5v0jyQhG6JMmBlb6%2FgTfL8z0%3D&amp;reserved=0).
>
> Is it possible to fix this or at least change the default
> auto-delete-queue setting?
>
> Thanks
> Brad
>
> Reproducer:
>
>
> @Autowired
> ConnectionFactory connectionFactory;
>
>
>
> @Test
> public void shouldDeliverMessagesAfterConsumerReconnects() throws
> JMSException, InterruptedException {
>     // #1 Connect a producer and consumer to a queue - address & queue
> will be auto created.
>     // #2 Send a message from producer and receive it from consumer -
> works fine.
>     // #3 Disconnect the consumer - queue now has no consumers and no
> messages, but the producer is still connected to the address.
>     // #4 Send another message from the producer.
>     // #5 Connect another consumer and try to receive the message from
> the queue.
>     // Expected: Message can be consumed from the queue.
>     // Actual: This will fail, there is no message to receive. There
> are no errors returned to the clients, nothing in the broker error
> logs, nothing in the DLQ.  The message is lost.
>
>     // proper resource cleanup omitted for brevity
>     String queueName = "ConsumerReconnects" + System.currentTimeMillis();
>     Connection sendingConnection = connectionFactory.createConnection();
>     sendingConnection.start();
>     Session sendingSession = sendingConnection.createSession(true, 0);
>     MessageProducer producer =
> sendingSession.createProducer(sendingSession.createQueue(queueName));
>
>     Connection recvConnection = connectionFactory.createConnection();
>     recvConnection.start();
>     Session recvSession = recvConnection.createSession(true, 0);
>     MessageConsumer consumer =
> recvSession.createConsumer(recvSession.createQueue(queueName));
>
>     // send a message
>     producer.send(sendingSession.createTextMessage("test 1"));
>     sendingSession.commit();
>
>     // verify it can be read OK
>     Message message = consumer.receive(2000);
>     assertNotNull(message);
>     assertEquals("test 1", message.getBody(String.class));
>     recvSession.commit();
>
>     // now disconnect the consumer and wait a while so that the
> auto-delete can kick in
>     consumer.close();
>     Thread.sleep(5000);
>
>     // send a message to the queue
>     producer.send(sendingSession.createTextMessage("test 2"));
>     sendingSession.commit();
>
>     // now connect another consumer
>     consumer =
> recvSession.createConsumer(recvSession.createQueue(queueName));
>     // verify it can be read OK
>     // This step will fail if queue auto deletion is not turned off
>     // <auto-delete-queues>false</auto-delete-queues>
>     message = consumer.receive(2000);
>     assertNotNull(message);
>     assertEquals("test 2", message.getBody(String.class));
>     recvSession.commit();
> }
>
>
>
>
>
>
> The information transmitted is intended only for the person or entity
> to which it is addressed and may contain confidential and / or
> privileged material that may be governed by confidential information
> provisions contained in the agreement between GBST and your company.
> Any disclosure, copying, distribution, or other use without the
> express consent of the sender is prohibited. If you received this in
> error, please contact the sender and delete the material from any
> computer. All rights in the information transmitted, including
> copyright, are reserved. Nothing in this message should be interpreted
> as a digital signature that can be used to authenticate a document. No
> warranty is given by the sender that any attachments to this email are free from viruses
or other defects.
>
The information transmitted is intended only for the person or entity to which it is addressed
and may contain confidential and / or privileged material that may be governed by confidential
information provisions contained in the agreement between GBST and your company. Any disclosure,
copying, distribution, or other use without the express consent of the sender is prohibited.
If you received this in error, please contact the sender and delete the material from any
computer. All rights in the information transmitted, including copyright, are reserved. Nothing
in this message should be interpreted as a digital signature that can be used to authenticate
a document. No warranty is given by the sender that any attachments to this email are free
from viruses or other defects.
Mime
View raw message