Re: Service org.springframework.transaction.PlatformTransactionManager missing after restart
Hi, Did you check the start-level in the features ? Regards JB On Tue, Feb 14, 2023 at 10:50 AM Ephemeris Lappis wrote: > > Hello again. > > After testing "refresh" or "restart" of bundles around transaction > management, with no success, I've tried a "feature:refresh" that seems > to have restarted the PlatformManager that was missing, and the > bundles that were waiting for it. In fact, I don't understand neither > what was failing nor why this "feature:refresh" has fixed it... > > An explanation should really be welcome : I think these days I'm going > to see and learn more things than ever in many years using SMX, Fuse > or karaf :) ... > > Thanks in advance. > > Regards. > > Le mar. 14 févr. 2023 à 10:07, Ephemeris Lappis > a écrit : > > > > Hello. > > > > When installing our applicative features that pull the dependent > > transaction features the service > > "org.springframework.transaction.PlatformTransactionManager" is up, > > provided by the Geronimo TM, and our bundles resolve it and work as > > expected. > > > > After stopping and restarting Karaf, the same bundles fail because the > > service is missing. Indeed, listing services do not show it anymore. > > > > I've seen very old messages about similar issues on Fuse. Is this > > issue still impacting Karaf 4.4.3, and in this case, what can we do to > > ensure all the services are present after a reboot ? > > > > Thanks for your help. > > > > Regards.
Re: Installing feature with Jolokia fails because of HTTP unexpected restart
Hi, I bet the refresh is due to optional import. Let me check the resolver output. Regards JB On Tue, Feb 14, 2023 at 2:55 PM Ephemeris Lappis wrote: > > Hello. > > After pax-jdbc-config, we've found another feature that restarts the > HTTP and that makes Jolokia fail : camel-bindy. I don't understand > why... > > To avoid the side-effect of installing pax-jdbc-config, we've added it > to the Karaf's boot feature as we know it's available from "raw" > install. This is an acceptable workaround. > > But for camel-bindy, as the Camel repository is not available at the > moment of the first install, we can't do the same. It's important for > us not to couple the version of Camel to Keraf image, and decide for > it later at deployment time. > > So, what feedback do you have on Jolokia's uses for deployments when > Jolokia itself can be impacted by side effects of someactions, and > fail during its own execution ? > > Thanks again for help ! > > Regards. > > Le lun. 13 févr. 2023 à 17:10, Ephemeris Lappis > a écrit : > > > > Hello. > > > > Reading my mail I see that the logs are missing. I added them at the > > end of this message... > > > > After more tests, it seems that the guilty module is pax-jdbc-config > > that registers something with http. Perhaps someone knows what and > > why... > > Adding manually this feature before produces the same side effect, and > > installing our feature with jolokia after doesn't fail anymore. > > > > The question is still how can we deploy with jolokia something that > > breaks the http request/response :( ? > > > > The missing logs : > > > > 15:28:56.947 INFO [qtp312812427-203] Adding features: > > caterpillar-system-jdbc/[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT] > > 15:28:57.481 INFO [features-3-thread-1] Changes to perform: > > 15:28:57.482 INFO [features-3-thread-1] Region: root > > 15:28:57.482 INFO [features-3-thread-1] Bundles to install: > > 15:28:57.483 INFO [features-3-thread-1] > > mvn:jakarta.el/jakarta.el-api/3.0.3 > > 15:28:57.483 INFO [features-3-thread-1] > > mvn:javax.enterprise/cdi-api/2.0.SP1 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:javax.interceptor/javax.interceptor-api/1.2.2 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:javax.transaction/javax.transaction-api/1.2 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:org.apache.commons/commons-dbcp2/2.9.0 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:org.apache.commons/commons-pool2/2.11.1 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1 > > 15:28:57.484 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1 > > 15:28:57.485 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3 > > 15:28:57.485 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5 > > 15:28:57.485 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5 > > 15:28:57.485 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5 > > 15:28:57.486 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.transx/pax-transx-tm-api/0.5.3 > > 15:28:57.486 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3 > > 15:28:57.486 INFO [features-3-thread-1] > > mvn:org.osgi/org.osgi.service.jdbc/1.0.1 > > 15:28:57.486 INFO [features-3-thread-1] > > mvn:org.apache.aries.tx-control/tx-control-service-local/1.0.1 > > 15:28:57.486 INFO [features-3-thread-1] > > mvn:org.apache.aries.tx-control/tx-control-service-xa/1.0.1 > > 15:28:57.487 INFO [features-3-thread-1] Installing bundles: > > 15:28:57.488 INFO [features-3-thread-1] > > mvn:jakarta.el/jakarta.el-api/3.0.3 > > 15:28:57.490 INFO [features-3-thread-1] > > mvn:javax.enterprise/cdi-api/2.0.SP1 > > 15:28:57.493 INFO [features-3-thread-1] > > mvn:javax.interceptor/javax.interceptor-api/1.2.2 > > 15:28:57.494 INFO [features-3-thread-1] > > mvn:javax.transaction/javax.transaction-api/1.2 > > 15:28:57.496 INFO [features-3-thread-1] > > mvn:org.apache.commons/commons-dbcp2/2.9.0 > > 15:28:57.498 INFO [features-3-thread-1] > > mvn:org.apache.commons/commons-pool2/2.11.1 > > 15:28:57.500 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1 > > 15:28:57.502 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1 > > 15:28:57.505 INFO [features-3-thread-1] > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3 > > 15:28:57.506 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5 > > 15:28:57.508 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5 > > 15:28:57.509 INFO [features-3-thread-1] > > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5 > > 15:28:57.510 INFO
Re: Installing feature with Jolokia fails because of HTTP unexpected restart
Hello. After pax-jdbc-config, we've found another feature that restarts the HTTP and that makes Jolokia fail : camel-bindy. I don't understand why... To avoid the side-effect of installing pax-jdbc-config, we've added it to the Karaf's boot feature as we know it's available from "raw" install. This is an acceptable workaround. But for camel-bindy, as the Camel repository is not available at the moment of the first install, we can't do the same. It's important for us not to couple the version of Camel to Keraf image, and decide for it later at deployment time. So, what feedback do you have on Jolokia's uses for deployments when Jolokia itself can be impacted by side effects of someactions, and fail during its own execution ? Thanks again for help ! Regards. Le lun. 13 févr. 2023 à 17:10, Ephemeris Lappis a écrit : > > Hello. > > Reading my mail I see that the logs are missing. I added them at the > end of this message... > > After more tests, it seems that the guilty module is pax-jdbc-config > that registers something with http. Perhaps someone knows what and > why... > Adding manually this feature before produces the same side effect, and > installing our feature with jolokia after doesn't fail anymore. > > The question is still how can we deploy with jolokia something that > breaks the http request/response :( ? > > The missing logs : > > 15:28:56.947 INFO [qtp312812427-203] Adding features: > caterpillar-system-jdbc/[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT] > 15:28:57.481 INFO [features-3-thread-1] Changes to perform: > 15:28:57.482 INFO [features-3-thread-1] Region: root > 15:28:57.482 INFO [features-3-thread-1] Bundles to install: > 15:28:57.483 INFO [features-3-thread-1] > mvn:jakarta.el/jakarta.el-api/3.0.3 > 15:28:57.483 INFO [features-3-thread-1] > mvn:javax.enterprise/cdi-api/2.0.SP1 > 15:28:57.484 INFO [features-3-thread-1] > mvn:javax.interceptor/javax.interceptor-api/1.2.2 > 15:28:57.484 INFO [features-3-thread-1] > mvn:javax.transaction/javax.transaction-api/1.2 > 15:28:57.484 INFO [features-3-thread-1] > mvn:org.apache.commons/commons-dbcp2/2.9.0 > 15:28:57.484 INFO [features-3-thread-1] > mvn:org.apache.commons/commons-pool2/2.11.1 > 15:28:57.484 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1 > 15:28:57.484 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1 > 15:28:57.485 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3 > 15:28:57.485 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5 > 15:28:57.485 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5 > 15:28:57.485 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5 > 15:28:57.486 INFO [features-3-thread-1] > mvn:org.ops4j.pax.transx/pax-transx-tm-api/0.5.3 > 15:28:57.486 INFO [features-3-thread-1] > mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3 > 15:28:57.486 INFO [features-3-thread-1] > mvn:org.osgi/org.osgi.service.jdbc/1.0.1 > 15:28:57.486 INFO [features-3-thread-1] > mvn:org.apache.aries.tx-control/tx-control-service-local/1.0.1 > 15:28:57.486 INFO [features-3-thread-1] > mvn:org.apache.aries.tx-control/tx-control-service-xa/1.0.1 > 15:28:57.487 INFO [features-3-thread-1] Installing bundles: > 15:28:57.488 INFO [features-3-thread-1] mvn:jakarta.el/jakarta.el-api/3.0.3 > 15:28:57.490 INFO [features-3-thread-1] > mvn:javax.enterprise/cdi-api/2.0.SP1 > 15:28:57.493 INFO [features-3-thread-1] > mvn:javax.interceptor/javax.interceptor-api/1.2.2 > 15:28:57.494 INFO [features-3-thread-1] > mvn:javax.transaction/javax.transaction-api/1.2 > 15:28:57.496 INFO [features-3-thread-1] > mvn:org.apache.commons/commons-dbcp2/2.9.0 > 15:28:57.498 INFO [features-3-thread-1] > mvn:org.apache.commons/commons-pool2/2.11.1 > 15:28:57.500 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1 > 15:28:57.502 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1 > 15:28:57.505 INFO [features-3-thread-1] > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3 > 15:28:57.506 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5 > 15:28:57.508 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5 > 15:28:57.509 INFO [features-3-thread-1] > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5 > 15:28:57.510 INFO [features-3-thread-1] > mvn:org.ops4j.pax.transx/pax-transx-tm-api/0.5.3 > 15:28:57.512 INFO [features-3-thread-1] > mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3 > 15:28:57.513 INFO [features-3-thread-1] > mvn:org.osgi/org.osgi.service.jdbc/1.0.1 > 15:28:57.515 INFO [features-3-thread-1] > mvn:org.apache.aries.tx-control/tx-control-service-local/1.0.1 > 15:28:57.516 INFO
Re: PAX JMS & Camel consumer produce warnings
Hello.
After a shutdown and restart of karaf, these messages have disappeared :) !
I've cleaned the Karaf cache and installed all my features again, and
no more warning messages. Should it be something like a "souvenir" of
my old feature with handmade CF in blueprint that was altering the new
feature with PAX JMS ???
Perhaps you can confirm that I pull all the needed features and set
all the PAX configuration ?
My current deployment is based on this feature to add the ActiveMQ
repository and pull the needed JMS client and PAX features :
http://karaf.apache.org/xmlns/features/v1.6.0;
name="caterpillar-system-jms">
mvn:org.apache.activemq/activemq-karaf/5.17.3/xml/features
Caterpillar :: System :: JMS connection factory
activemq-client
pax-jms-activemq
pax-jms-pool-pooledjms
pax-jms-config
And this configuration file (only one non XA CF for now) :
# Connection configuration
type=activemq
connectionFactoryType=ConnectionFactory
# Names
name=alice-jms
osgi.jndi.service.name=jms/alice
# Connection factory properties
jms.url=tcp://localhost:6000
jms.user=application
jms.password=secret
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
Le mar. 14 févr. 2023 à 07:36, Grzegorz Grzybek a écrit :
>
> Hello
>
> I'm glad to hear about good work of Pax JDBC!
>
> `pool=pooledjms` means that the pool from org.messaginghub/pooled-jms is used
> (which uses commons-pool2 underneath).
>
> We'd have to see some more configuration and more error messages (stack
> traces) than just "Cause: The Consumer is closed"... Do you use blueprint to
> configure the pool?
>
> For example, here's a blueprint where I configure pooled-jms using:
> - blueprint:
> https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/persistence/message-brokers/blueprints/artemis-manual.xml
> - configadmin only:
> https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-x/persistence/message-brokers/cm/org.ops4j.connectionfactory-artemis.cfg
>
> these are all part of Red Hat Fuse 7 quickstarts. I hope these will give you
> some hints, but anyway - please show more config/stacktraces.
>
> regards
> Grzegorz Grzybek
>
> wt., 14 lut 2023 o 07:21 Ephemeris Lappis
> napisał(a):
>>
>> Hello.
>>
>> Yes, I use PAX JMS, installing it with this feature (adding the ActiveMQ
>> 5.17.3 repository and PAX dependencies) :
>>
>>
>> http://karaf.apache.org/xmlns/features/v1.6.0;
>> name="${project.artifactId}">
>> mvn:org.apache.activemq/activemq-karaf/${version.of.activemq}/xml/features
>>
>> > version="${version.of.activemq}">activemq-client
>> pax-jms-activemq
>> pax-jms-pool-pooledjms
>> pax-jms-config
>>
>>
>>
>> And with this configuration file :
>>
>> type=activemq
>> connectionFactoryType=ConnectionFactory
>> name=alice-jms
>> osgi.jndi.service.name=jms/test
>> jms.url=tcp://localhost:6000
>> jms.user=application
>> jms.password=secret
>> jms.clientIDPrefix=CATERPILLAR
>> xa=false
>> pool=pooledjms
>> pool.maxConnections=256
>>
>> I don't think this come from the ActiveMQ client (not server) : I used
>> the same before with a connection factory created by a blueprint, with
>> more 2 millions messages sent/received in tests with the same Camel
>> routes, and after several days running.
>>
>> Now the warning messages come after seconds or minutes, as if the pool
>> was altered by some cleaning operation on live connections.
>>
>> I also use PAX JDBC, that works perfectly :) !
>>
>> Thanks.
>>
>> Regards.
>>
>> Ephemeris Lappis
>>
>> Le 14/02/2023 à 06:58, Jean-Baptiste Onofré a écrit :
>> > Are you using camel-jms ? What's the camel endpoint URI ?
>> >
>> > Regards
>> > JB
>> >
>> > On Mon, Feb 13, 2023 at 7:17 PM Ephemeris Lappis
>> > wrote:
>> >> Hello.
>> >>
>> >> I've changed a handmade JMS Connection factory to use PAX JMS with
>> >> pooling.
>> >> Now I've strange warning messages that come after some time :
>> >>
>> >> DefaultJmsMessageListenerContainer | 209 -
>> >> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 | | Setup of JMS
>> >> message listener invoker failed for destination
>> >> 'bbbmmm999-f902.internal.queue' - trying to recover. Cause: The
>> >> Consumer is closed
>> >>
>> >> Each time, I have a message for every Camel route consumer.
>> >>
>> >> Is it a configuration issue on PAX JMS ? For now I've not set any
>> >> parameters about idle time and so on : only maximum connections...
>> >>
>> >> pool=pooledjms
>> >> pool.maxConnections=256
>> >>
>> >> Thanks for your help.
>> >>
>> >> Thanks.
>>
>> --
>> Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
>> www.avast.com
Re: Service org.springframework.transaction.PlatformTransactionManager missing after restart
Hello again. After testing "refresh" or "restart" of bundles around transaction management, with no success, I've tried a "feature:refresh" that seems to have restarted the PlatformManager that was missing, and the bundles that were waiting for it. In fact, I don't understand neither what was failing nor why this "feature:refresh" has fixed it... An explanation should really be welcome : I think these days I'm going to see and learn more things than ever in many years using SMX, Fuse or karaf :) ... Thanks in advance. Regards. Le mar. 14 févr. 2023 à 10:07, Ephemeris Lappis a écrit : > > Hello. > > When installing our applicative features that pull the dependent > transaction features the service > "org.springframework.transaction.PlatformTransactionManager" is up, > provided by the Geronimo TM, and our bundles resolve it and work as > expected. > > After stopping and restarting Karaf, the same bundles fail because the > service is missing. Indeed, listing services do not show it anymore. > > I've seen very old messages about similar issues on Fuse. Is this > issue still impacting Karaf 4.4.3, and in this case, what can we do to > ensure all the services are present after a reboot ? > > Thanks for your help. > > Regards.
Service org.springframework.transaction.PlatformTransactionManager missing after restart
Hello. When installing our applicative features that pull the dependent transaction features the service "org.springframework.transaction.PlatformTransactionManager" is up, provided by the Geronimo TM, and our bundles resolve it and work as expected. After stopping and restarting Karaf, the same bundles fail because the service is missing. Indeed, listing services do not show it anymore. I've seen very old messages about similar issues on Fuse. Is this issue still impacting Karaf 4.4.3, and in this case, what can we do to ensure all the services are present after a reboot ? Thanks for your help. Regards.
