Regarding Bug ARTEMIS-3351

[Marcus Ionker]

Hello,

We were also impacted by a “Zombie” Consumer and/or Session – eg because the 
Session was closed in the Admin. Console - that causes the MessageConsumer to 
“hang” indefinitely, exactly the issue reported in 
https://issues.apache.org/jira/browse/ARTEMIS-3351. I tested this issue with 
Artemis Broker version 2.39.0 and the artemis-jms-client-all Java library 
version 2.39.0.

Here are my jndi settings.

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.ConnectionFactory=tcp://localhost:61616?retryInterval=1000&retryIntervalMultiplier=1.5&maxRetryInterval=60000&reconnectAttempts=1000
queue.queue/exampleQueue=exampleQueue

Here is the sample test code

package org.example;

import javax.jms.*;
import javax.naming.InitialContext;

public class Main {
    public static void main(String[] args) throws Exception {

        Connection connection = null;
        InitialContext initialContext = null;
        try {
            // Step 1. Create an initial context to perform the JNDI lookup.
            initialContext = new InitialContext();
            // Step 2. Perform a lookup on the queue
            Queue queue = (Queue) initialContext.lookup("queue/exampleQueue");
            // Step 3. Perform a lookup on the Connection Factory
            ConnectionFactory cf = (ConnectionFactory) 
initialContext.lookup("ConnectionFactory");
            // Step 4.Create a JMS Connection
            connection = cf.createConnection("artemis", "artemis");
            // Step 5. Create a JMS Session
            Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
            // Step 6. Create a JMS Message Producer
            MessageProducer producer = session.createProducer(queue);
            // Step 7. Create a Text Message
            //TextMessage message = session.createTextMessage("This is a text 
message");
            //System.out.println("Sent message: " + message.getText());
            // Step 8. Send the Message
            //producer.send(message);
            // Step 9. Create a JMS Message Consumer
            MessageConsumer messageConsumer = session.createConsumer(queue);
            // Step 10. Start the Connection
            connection.start();
            // Step 11. Receive the message
            TextMessage messageReceived = (TextMessage) 
messageConsumer.receive(30000);
            if (messageReceived != null) {
                System.out.println("Received message: " + 
messageReceived.getText());
            }
        } finally {
            // Step 12. Be sure to close our JMS resources!
            if (initialContext != null) {
                initialContext.close();
            }
            if (connection != null) {
                connection.close();
            }
        }

    }
}

Based on my research I observed the following.


  *   the first time the wait(toWait) - 
https://github.com/apache/activemq-artemis/blob/2.39.0/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L269
 -  is called with my desired timeout. Even if the session is closed in the 
admin console code execution continues after the desired timeout
  *   then the private method private ClientMessage receive(final long timeout, 
final boolean forcingDelivery) throws ActiveMQException – ClientConsumerImpl 
line 201 – is exited and processing returns to the public method public 
ClientMessage receive(final long timeout) throws ActiveMQException - 
ClientConsumerImpl line 374.
  *   if (msg == null && !closed) is true - ClientConsumerImpl line 378 – so 
the private receive method is called again with timeout = 0 and 
forcingDelivery=true.
  *   Now while ((stopped || (m = buffer.poll()) == null) && !closed && toWait 
> 0) - ClientConsumerImpl line251 – is entered once and then exited at 
ClientConsumerImpl line 262
  *   The forceDelivery is executed at ClientConsumerImpl line 305
  *   The while loop at ClientConsumerImpl line 247 is executed again and the 
wait(toWait) is executed with Long.MAX_VALUE.
  *   The consumer now waits virtually “forever” and the forceDelivery response 
from the server never arrives.

I hope I may have helped to address this issue – Artemis-3351.

Best Regards,
Marcus



[Retarus 
Logo]<https://www.retarus.com/?utm_source=footer&utm_medium=email&utm_content=weblink&utm_campaign=global-email-signature-new>

Marcus Ionker | Senior Product Evangelist, Messaging | M +49 176 
15528012<tel:+49%20176%2015528012>
F +49 89 1250400-1202<tel:+49%2089%201250400-1202> | 
marcus.ion...@retarus.com<mailto:marcus.ion...@retarus.com>

retarus GmbH | Aschauer Straße 30, 81549 München, Germany | 
www.retarus.com<https://www.retarus.com/?utm_source=footer&utm_medium=email&utm_content=weblink&utm_campaign=global-email-signature-new>

smime.p7s
Description: S/MIME cryptographic signature