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 <[email protected]> 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 <[email protected]> > Sent: Tuesday, 13 October 2020 6:25 PM > To: [email protected] > 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&data=02%7C01%7CBrad.Harvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&sdata=qmrFFt%2ByFp9OjDRSXnllHMpkuwAyIBfdnPge%2Ben9uGQ%3D&reserved=0 > > Regards, > Domenico > > Il giorno mar 13 ott 2020 alle ore 07:21 Brad Harvey <[email protected]> > 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&data=02%7C01%7CBrad.H > > arvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&sdata=sV2Ww7KhBvNfcpJLMb0h02fJXG8uV1usSUr1NLKgp%2Fw%3D&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&data=02%7C01%7CBrad.Harvey%40gbst.com%7C3936bf839b664fdb2d0a08d86f517790%7C1c2da354196b481891e4f760cbaac9e4%7C0%7C0%7C637381743019172958&sdata=OdRQPXwGLF1TXyiUFRN5v0jyQhG6JMmBlb6%2FgTfL8z0%3D&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
