+1 for that :)
François
[email protected]
[email protected]
Le 25/03/2026 à 20:37, Jean-Baptiste Onofré a écrit :
That's my point: I'm not comfortable to depend on Pax / Aries inactive
projects. I think it's easier and more "visible" to maintain in Karaf.
We can always re-add these projects later once they will be updated.
If we wait all projects to migrate to Jakarta namespace, we will
release Karaf 4.5.0 in 6 months :)
So, I propose to cleanup for now for Karaf 4.5.0 and re-add the
third-party projects when they are ready.
Regards
JB
On Wed, Mar 25, 2026 at 8:30 PM Grzegorz Grzybek
<[email protected]> wrote:
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-jms
osgi.jndi.service.name
<http://osgi.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 |
