ś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 >>>>> >>>>>
