> 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]> 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] > For additional commands, e-mail: [email protected] > >
