Hello again ! Here is the new ticket : https://github.com/ops4j/org.ops4j.pax.jms/issues/65.
I hope you have enough to work on it. Please ask me for more details if needed... Thanks again. Regards. Le jeu. 13 juil. 2023 à 16:33, Grzegorz Grzybek <[email protected]> a écrit : > > 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.
