activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: artemis auto queue deletion results in lost messages
Date Thu, 15 Oct 2020 14:37:09 GMT
We thought about changing the default to not auto-delete queues... but
we were afraid of users complaining the opposite.

anyone would have any objections on changing the default for the next
version?... it wouldn't be a default hard coded on the .java, but new
configurations and new broker creations would have it off on the XML.

On Thu, Oct 15, 2020 at 1:57 AM Brad Harvey <Brad.Harvey@gbst.com> wrote:
>
> 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.



-- 
Clebert Suconic

Mime
View raw message