Thanks for the issue. I can't promise I'll have a look tomorrow, but it should be soon enough ;)
regards Grzegorz Grzybek czw., 13 lip 2023 o 17:10 Ephemeris Lappis <[email protected]> napisał(a): > 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. >
