By the way, while working on https://github.com/apache/karaf/pull/2476 (migrating from javax to jakarta), I just realized that Pax JMS is JMS 1.x only for now.
Honestly, as Pax CDI, I'm not sure it makes sense to still use/maintain Pax JMS. I would rather suggest using a service provider (custom): I'm updating the examples as part of the PR. Also, we can add a new Karaf service (easier to maintain) dealing with JMS ConnectionFactories (similar to Karaf URL service). Regards JB On Wed, Mar 25, 2026 at 12:57 PM Grzegorz Grzybek <[email protected]> wrote: > > > śr., 25 mar 2026 o 12:42 Ephemeris Lappis <[email protected]> > napisał(a): > >> Hello again. >> >> Just to be sure : pax jms uses the provider to create the actual >> connection factory, and in our case it's >> "org.apache.activelmq.ActiveMQConnectionFactory", and this implementation >> doesn't provide a "close" method, right ? >> > > Yes, correct... > > >> >> So,with no help from pw jms itself, how can we handle this, even if it's >> just a workaround ? I suppose we could code something to close connections, >> but how can we get reference on the pool or the connection factory ? >> > > You'd have to use OSGi service tracking to get a service of class > javax.jmx.ConnectionFactory - using "standard" OSGi ServiceTracker. Then > you'd have to do (I think) some reflection code to get the pool > details........ > > ~Grzegorz Grzybek > > >> >> Thanks again. >> >> >> Le mer. 25 mars 2026 à 12:22, Grzegorz Grzybek <[email protected]> a >> écrit : >> >>> Hello >>> >>> śr., 25 mar 2026 o 12:12 Ephemeris Lappis <[email protected]> >>> napisał(a): >>> >>>> Hello. >>>> >>>> Thanks for your answer... >>>> >>>> I don't actually understand when you say that application are in >>>> charge of closing connections : in ou world, application are Camel routes >>>> in feature that are all uninstalled when the pax jms itself is removing, >>>> and logs show clearly how routes are stopped and removed when each Camel >>>> feature is uninstalled. >>>> >>> >>> This is just a typical case - even with Camel - JMS connection is taken >>> from the pool, used and "closed" (which with the pool usually means >>> returning to the pool without closing it). >>> And I see that it may be a problem, because Pax JMS creates the pool >>> based on JMS provider specific implementation of >>> javax.jms.ConnectionFactory, but there's no "close" method on the factory... >>> >>> I'm afraid this scenario would require extending generic Pax JMS support >>> for dynamic reconfiguration... >>> >>> regards >>> Grzegorz Grzybek >>> >>> >>>> >>>> When the pax-jms-config feature is removed, we expect that it delete >>>> the pool, and thus close any remaining connection, but in some random case, >>>> it doesn't do it, and when all the features are installed back, a new pool >>>> is created, and 256 connections are potentially added on the broker, until >>>> it fails... >>>> >>>> Thanks again. >>>> >>>> Le mer. 25 mars 2026 à 11:22, Grzegorz Grzybek <[email protected]> >>>> a écrit : >>>> >>>>> Hello >>>>> >>>>> While I was involved in maintenance of Pax JMS library I don't >>>>> remember any issues related to hanging connections... >>>>> >>>>> To be honest this project is in kind of awaiting state, almost killed >>>>> by the unnecessary move from "javax" to "jakarta"... There's still no >>>>> jakarta.jmx version of this library (would require similar change in Pax >>>>> Transx project..). >>>>> >>>>> I see that Pax JMS does some special treatment if the implementation >>>>> of javax.jms.ConnectionFactory is AutoCloseable, >>>>> but org.apache.activemq.ActiveMQConnectionFactory is not. >>>>> So it's the responsibility of the application to properly close the >>>>> connections... >>>>> >>>>> That's all I can help with ;( >>>>> >>>>> kind regards >>>>> Grzegorz Grzybek >>>>> >>>>> śr., 25 mar 2026 o 10:45 Ephemeris Lappis <[email protected]> >>>>> napisał(a): >>>>> >>>>>> Hello. >>>>>> >>>>>> We use pax-jms-config to manage JMS (ActiveMQ) connection factories. >>>>>> It basically works as expected, but we've recently observed a critical >>>>>> issue : it seems that with some unidentified conditions, when the >>>>>> features >>>>>> are installed/uninstalled, or connection factories cfg files updated, the >>>>>> current connections are not closed, and new ones are created. We can see >>>>>> the corresponding sockets on both Karaf and ActiveMQ (or in activemq >>>>>> console). When the maximum configured connection count is exceeded, all >>>>>> the >>>>>> system (including other JMS clients) fails. >>>>>> >>>>>> Is it a known issue ? If not, is there any way to force the jms pool >>>>>> to be cleaned ? >>>>>> >>>>>> Below are our feature structure and configuration file... >>>>>> Thanks again. >>>>>> >>>>>> Best regards. >>>>>> >>>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>>>>> >>>>>> <features >>>>>> >>>>>> xmlns="http://karaf.apache.org/xmlns/features/v1.6.0"; >>>>>> >>>>>> name="${project.artifactId}"> >>>>>> >>>>>> >>>>>> <repository> >>>>>> mvn:org.apache.activemq/activemq-karaf/${version.of.activemq}/xml/features >>>>>> </repository> >>>>>> >>>>>> >>>>>> <feature >>>>>> >>>>>> name="${project.artifactId}" >>>>>> >>>>>> version="${project.version}"> >>>>>> >>>>>> <feature prerequisite="true" version="${version.of.activemq}"> >>>>>> activemq-client</feature> >>>>>> >>>>>> <feature prerequisite="true">base-system</feature> >>>>>> >>>>>> <feature prerequisite="true">pax-jms-activemq</feature> >>>>>> >>>>>> <feature prerequisite="true">pax-jms-pool-pooledjms</feature> >>>>>> >>>>>> <feature prerequisite="true">pax-jms-config</feature> >>>>>> >>>>>> </feature> >>>>>> >>>>>> >>>>>> </features> >>>>>> >>>>>> >>>>>> # Connection configuration >>>>>> type=activemq >>>>>> connectionFactoryType=ConnectionFactory >>>>>> >>>>>> # Names >>>>>> name=xxx-jmsosgi.jndi.service.name=jms/xxx >>>>>> >>>>>> # Connection factory properties >>>>>> jms.url=tcp://amq-service:61616 >>>>>> jms.user=application >>>>>> jms.password=secret >>>>>> jms.clientIDPrefix=ID >>>>>> >>>>>> # Set XA transaction >>>>>> xa=false >>>>>> >>>>>> # Connection pooling >>>>>> pool=pooledjms >>>>>> pool.maxConnections=256 >>>>>> >>>>>>
