Hello Grzegorz. Before creating a JIRA, I've done some new tests : I've seen that on environments where the issue appears, we have some additional properties for the connection pool :
pool.connectionIdleTimeout=30 pool.connectionCheckInterval=15000 I've tried to remove these two properties, and the connection is not closed anymore. I've also tried to leave only the check interval, and it also works. Setting the connectionIdleTimeout with "3", "5" or "10" works too (strange). Setting again this property with "30" breaks again the connection after 30 minutes (very strange); So I have not a very clear idea of the actual role of "pool.connectionIdleTimeout", since the tested values do not clearly show how it changes the behavior : I expected the connection to be closed after 3, 5 or 10 minutes, but nothing of that ! Anyway, it seems very strange that the pooling connection factory considere as idle a connection that is used by a consuming Camel route, no ? I use Karaf 4.4.3 with the corresponding installed pax features : pax-jms-core (0x 1.1.2 │ │ Started │ pax-jms-1.1.2 │ pax-jms-config (0x 1.1.2 │ │ Started │ pax-jms-1.1.2 │ pax-jms-activemq (0x 1.1.2 │ │ Started │ pax-jms-1.1.2 │ pax-jms-pool-pooledjms (0x 1.1.2 │ │ Started │ pax-jms-1.1.2 │ I attach a failing configuration file. Should I create a ticket with this ambiguous analysis ? Thanks for your help. Regards. Le jeu. 13 juil. 2023 à 13:13, Grzegorz Grzybek <[email protected]> a écrit : > > Hello > > May I ask you to create an issue at > https://github.com/ops4j/org.ops4j.pax.jms/issues ? > > Please attach the configuration, paste the logs and show which pax-jms > version do you use. > > thanks in advance > Grzegorz Grzybek > > czw., 13 lip 2023 o 12:42 Ephemeris Lappis <[email protected]> > napisał(a): >> >> Hello. >> >> We observed a strange behavior on our JMS connections that we manage >> using a PAX JMS factory. Connections used by Camel consumers, with or >> without activity, seem to be closed after 30 minutes. A tcpdump on the >> karaf side shows that a connection with a consumer has its >> InactivityMonitor that sends a "KeepAliveInfo" every 10 seconds, but >> ends after 30 minutes with 2 "RemoveInfo" (probably closing the >> consumer and the session) and "ShutdownInfo" (probably closing the >> connection itself). This happens when no real traffic is done on the >> queue, but also when messages are sent and consumed every minute. >> >> Here are the logs that show the Camel consumer that detects the close >> connection every 30 minutes : >> >> 2023-07-13T10:32:46,824 | WARN | Camel (appvte002-f027_context) >> thread #50 - JmsConsumer[appvte002-f027.internal.queue] | >> DefaultJmsMessageListenerContainer | 222 - >> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 | | Setup of JMS >> message listener invoker failed for destination >> 'appvte002-f027.internal.queue' - trying to recover. Cause: The >> Session is closed >> 2023-07-13T11:02:47,422 | WARN | Camel (appvte002-f027_context) >> thread #51 - JmsConsumer[appvte002-f027.internal.queue] | >> DefaultJmsMessageListenerContainer | 222 - >> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 | | Setup of JMS >> message listener invoker failed for destination >> 'appvte002-f027.internal.queue' - trying to recover. Cause: The >> Consumer is closed >> 2023-07-13T11:32:47,982 | WARN | Camel (appvte002-f027_context) >> thread #52 - JmsConsumer[appvte002-f027.internal.queue] | >> DefaultJmsMessageListenerContainer | 222 - >> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 | | Setup of JMS >> message listener invoker failed for destination >> 'appvte002-f027.internal.queue' - trying to recover. Cause: The >> Consumer is closed >> 2023-07-13T12:02:48,595 | WARN | Camel (appvte002-f027_context) >> thread #53 - JmsConsumer[appvte002-f027.internal.queue] | >> DefaultJmsMessageListenerContainer | 222 - >> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 | | Setup of JMS >> message listener invoker failed for destination >> 'appvte002-f027.internal.queue' - trying to recover. Cause: The >> Consumer is closed >> >> Here is our PAX configuration : >> >> # Connection configuration >> type=activemq >> connectionFactoryType=ConnectionFactory >> >> # Names >> name=alice-jms >> osgi.jndi.service.name=jms/alice >> >> # Connection factory properties >> #jms.url=failover:(tcp://mq1:61616,tcp://mq2:61616) >> jms.url=tcp://mq1:61616 >> jms.user=karaf >> jms.password=karaf >> jms.clientIDPrefix=CATERPILLAR >> >> # Set XA transaction >> xa=false >> >> # Connection pooling >> pool=pooledjms >> # Maximum number of connections for each user+password (default 1) >> pool.maxConnections=256 >> >> Do you know if the PAX connection factory, with the given pooling >> option, may be at the origin of such connection closing ? I don't see >> why the Camel endpoint could close its own consumer... If this is a >> PAX behavior, what option should be set to avoid it ? >> >> Thanks for your help. >> >> Regards.
org.ops4j.connectionfactory-alice.cfg
Description: Binary data
