Good evening! One more thing - Pax JMS was a JMS equivalent of Pax JDBC. However, while Pax JDBC is actual implementation of https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.jdbc.html, there's no related "standard" specification for JMS... So another reason to not maintain Pax JMS...
Pax JMS is also related to Pax Transx (even lower level, but for transactions, which were hit even harder by javax → jakarta transition)... And Pax Transx depends on Geronimo TM and Aries TM which are not very active... There are some outstanding PRs related to this migration: - https://github.com/ops4j/org.ops4j.pax.jms/pull/72 - https://github.com/ops4j/org.ops4j.pax.transx/pull/74 - https://github.com/apache/aries/pull/790 kind regards Grzegorz Grzybek śr., 25 mar 2026 o 19:01 Jean-Baptiste Onofré <[email protected]> napisał(a): > 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 >>>>>>> >>>>>>>
