Hello pool.connectionIdleTimeout is something we can start with ;) At least the value matches your observation.
And yest please create GH issue - it's easier to work on a problem on GitHub than on mailing list ;) regards Grzegorz Grzybek czw., 13 lip 2023 o 16:05 Ephemeris Lappis <[email protected]> napisał(a): > 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. >
