You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Ephemeris Lappis <ep...@gmail.com> on 2023/07/13 10:41:04 UTC
PAX JMS connection factory / connection is closed after 30 minutes
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.
Re: PAX JMS connection factory / connection is closed after 30 minutes
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <ep...@gmail.com>
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 <gr...@gmail.com> 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 <ep...@gmail.com>
> 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 <gr...@gmail.com>
> 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 <
> ephemeris.lappis@gmail.com> 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.
>
Re: PAX JMS connection factory / connection is closed after 30 minutes
Posted by Ephemeris Lappis <ep...@gmail.com>.
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 <gr...@gmail.com> 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 <ep...@gmail.com> 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 <gr...@gmail.com> 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 <ep...@gmail.com> 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.
Re: PAX JMS connection factory / connection is closed after 30 minutes
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <ep...@gmail.com>
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 <gr...@gmail.com> 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 <ep...@gmail.com>
> 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.
>
Re: PAX JMS connection factory / connection is closed after 30 minutes
Posted by Ephemeris Lappis <ep...@gmail.com>.
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 <gr...@gmail.com> 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 <ep...@gmail.com> 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.
Re: PAX JMS connection factory / connection is closed after 30 minutes
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <ep...@gmail.com>
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.
>