What we should probably do is to close the whole connection when you close a session.
Session is a concept I’m trying to end anyways in the Jakarta spec. (Too early to say ) But for now. Can you close the connection instead ? Clebert Suconic On Fri, Mar 14, 2025 at 9:30 AM Marcus Ionker <marcus.ion...@retarus.com> wrote: > 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 > > > > [image: 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 <+49%20176%2015528012> > F +49 89 1250400-1202 <+49%2089%201250400-1202> | > marcus.ion...@retarus.com > > *retarus GmbH* | Aschauer Straße 30 > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g>, > > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g> > 81549 > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g> > München > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g>, > > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g> > Germany > <https://www.google.com/maps/search/Aschauer+Stra%C3%9Fe+30+,%0D%0A+81549+M%C3%BCnchen+,%0D%0A+Germany?entry=gmail&source=g> > | www.retarus.com > <https://www.retarus.com/?utm_source=footer&utm_medium=email&utm_content=weblink&utm_campaign=global-email-signature-new> > > >
