Hi Justin, thank you for the quick answer. The hint about deactivating the idle checking was helpful! 😊
Best regards Grzegorz ________________________________ Von: Justin Bertram <[email protected]> Gesendet: Mittwoch, 17. Dezember 2025 05:37 An: [email protected] Betreff: Re: Artemis-core-client: Repeated ActiveMQNotConnectedExceptions/'Closed session' IllegalStateExceptions when using httpEnabled=true (Configuring Netty HTTP) and default httpClientIdleTime Looking at this more, I believe you can simply disable the HTTP-specific idle checking using httpClientIdleScanPeriod=-1 and rely on the normal ping mechanism [1] to keep the connection alive. I'll probably actually remove the HTTP-specific idle stuff completely and update the docs as it seems to duplicate the existing ping functionality. Justin [1] https://github.com/apache/artemis/blob/main/docs/user-manual/connection-ttl.adoc#detecting-failure-from-the-client On Tue, Dec 16, 2025 at 9:01 PM Justin Bertram <[email protected]<mailto:[email protected]>> wrote: > Is the abserved behaviour a bug in Artemis codebase? Yes, I believe it is. I've opened a Jira to track this [1]. > Or are we configuring something wrong? No. > What are "appropriate" values for httpClientIdleTime and why? Assuming everything works like it is supposed to (which it currently isn't), "appropriate" values really depend on your use-case. With settings like this you should aim strike a balance between enough requests to keep an idle connection alive (assuming you want to) and not wasting bandwidth with unnecessary requests. > Shouldn't the default values work out-of-the-box? Generally speaking, defaults should work out-of-the-box. However, they won't always work out-of-the-box which is why they are configurable in the first place. You will need to determine what values work best for your use-case. > Would it be possible to add more detail to the documentation...? Yes. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-5819 On Tue, Dec 16, 2025 at 7:53 AM Stepien, Grzegorz via users <[email protected]<mailto:[email protected]>> wrote: Hi, we are trying to configure our Artemis Client for HTTP-based communication and are running into repeated connection losses when using the default httpClientIdleTime setting. We are unsure whether this is a configuration error on our end or an Artemis bug. Maybe some of you can help? Background: - We have an ActiveMQ Artemis 2.44.0 broker instance running in our company-cloud - We have a Spring-Boot-based client application which listens on various queues and topics on that broker instance - Several instances of that client application are deployed at various customers on-premise -- Out client has a 'spring-boot-starter-artemis' dependency (3.5.8) and an artemis-bom dependency (2.44.0) --- We could also reproduce the problem with artemis versions 2.41.0 and 2.42.0 (both client and broker) and also with older spring boot versions so it does not seem to be a new phenomenon. -- The Client registers several queue and topic listeners using a JmsListenerEndpointRegistrar Now several of our customers only allow outgoing HTTP communicaion which is why we have been experimenting with configuring our Client to use HTTP-Transport as explained in "https://artemis.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-http";. This results in the erros described below: Setup: I have reproduced the problem locally: I have an artemis 2.44.0 running on my local machine and try to connect to that artemis with our spring boot client application (also running locally) using "spring.artemis.broker-url=tcp://localhost:61616?httpEnabled=true". This, unfortunately, results in the connection to the broker being periodically closed an reestablished resulting in the some nasty Error-Logs on both client and broker side ("spring.artemis.broker-url=tcp://localhost:61616" works fine): Client side: "Caused by: org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: [errorType=NOT_CONNECTED message=AMQ219006: Channel disconnected] at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:417) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener.lambda$connectionDestroyed$0(NettyConnector.java:1254) ... 6 more ... 2025-12-16T14:09:38,480+01 o.s.j.c.CachingConnectionFactory: Encountered a JMSException - resetting the underlying JMS Connection jakarta.jms.IllegalStateException: Session is closed at org.apache.activemq.artemis.jms.client.ActiveMQSession.checkClosed(ActiveMQSession.java:1416) at org.apache.activemq.artemis.jms.client.ActiveMQSession.getTransacted(ActiveMQSession.java:302) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:422) at jdk.proxy2/jdk.proxy2.$Proxy138.getTransacted(Unknown Source) at org.springframework.jms.listener.AbstractMessageListenerContainer.commitIfNecessary(AbstractMessageListenerContainer.java:858) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:373) ..." Broker side: "2025-12-16 14:09:39,526 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 79f58d98-da80-11f0-aced-0a0027000018 2025-12-16 14:09:39,527 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session 79f58d98-da80-11f0-aced-0a0027000018 2025-12-16 14:09:39,527 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 79f5dbb9-da80-11f0-aced-0a0027000018 2025-12-16 14:09:39,528 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session 79f5dbb9-da80-11f0-aced-0a0027000018 2025-12-16 14:09:39,528 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 79f650ea-da80-11f0-aced-0a0027000018 ..." Now I have done some digging in the artemis codebase and it seems that the default value for httpClientIdleTime is 500ms. I have experimented around with that value and it seems that the above problems disappear if httpClientIdleTime is set to a large enough value - 1s seems to be a threshold where the errors disappear on my local machine: "spring.artemis.broker-url=tcp://localhost:61616?httpEnabled=true&httpClientIdleTime=1000". I am no expert on the artemis code, but I have noticed that the org.apache.activemq.artemis.core.remoting.impl.netty.HttpAcceptorHandler.channelRead(...) method (artemis-server module) only schedules a new response for POST requests while the org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.HttpIdleTimer.run() method (artemis-core-client module) sends an empty "keep-alive" GET request. Is it possible that the latter never gets answered resulting in the observed errors? So my question pretty much boils down to: - Is the abserved behaviour a bug in Artemis codebase? - Or are we configuring something wrong? What are "appropriate" values for httpClientIdleTime and why? Shouldn't the default values work out-of-the-box? Thank you and best regards! Grzegorz P.S.: Would it be possible to add more detail to the documentation at https://artemis.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-http? It is quite vague about what those parameters do in detail, which ones are to be set on the broker- and which on the client-side, what their unit is (second or millisecond?) and what their default values are. I had to look that up in the codebase. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]>
