You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@artemis.apache.org by "Stepien, Grzegorz via users" <us...@artemis.apache.org> on 2025/12/16 13:53:03 UTC
Artemis-core-client: Repeated ActiveMQNotConnectedExceptions/'Closed session' IllegalStateExceptions when using httpEnabled=true (Configuring Netty HTTP) and default httpClientIdleTime
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: users-unsubscribe@artemis.apache.org
For additional commands, e-mail: users-help@artemis.apache.org
AW: Artemis-core-client: Repeated ActiveMQNotConnectedExceptions/'Closed session' IllegalStateExceptions when using httpEnabled=true (Configuring Netty HTTP) and default httpClientIdleTime
Posted by "Stepien, Grzegorz via users" <us...@artemis.apache.org>.
Hi Justin,
thank you for the quick answer. The hint about deactivating the idle checking was helpful! 😊
Best regards
Grzegorz
________________________________
Von: Justin Bertram <jb...@apache.org>
Gesendet: Mittwoch, 17. Dezember 2025 05:37
An: users@artemis.apache.org
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 <jb...@apache.org>> 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 <us...@artemis.apache.org>> 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: users-unsubscribe@artemis.apache.org<ma...@artemis.apache.org>
For additional commands, e-mail: users-help@artemis.apache.org<ma...@artemis.apache.org>
Re: Artemis-core-client: Repeated ActiveMQNotConnectedExceptions/'Closed session' IllegalStateExceptions when using httpEnabled=true (Configuring Netty HTTP) and default httpClientIdleTime
Posted by Justin Bertram <jb...@apache.org>.
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 <jb...@apache.org> 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 <
> users@artemis.apache.org> 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: users-unsubscribe@artemis.apache.org
>> For additional commands, e-mail: users-help@artemis.apache.org
>>
>>
Re: Artemis-core-client: Repeated ActiveMQNotConnectedExceptions/'Closed session' IllegalStateExceptions when using httpEnabled=true (Configuring Netty HTTP) and default httpClientIdleTime
Posted by Justin Bertram <jb...@apache.org>.
> 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 <
users@artemis.apache.org> 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: users-unsubscribe@artemis.apache.org
> For additional commands, e-mail: users-help@artemis.apache.org
>
>