śr., 26 cze 2019 o 09:43 Kushal Gautam <[email protected]> napisał(a):
> Hi: > > Yes, that doesn't have a pool config right now. I was testing with and > without pool configs in pax-jms, but then I might have pushed the one > without pool config. > > I had to switch to blueprint based provider as I was able to process just > 2-3 messages per second(with pax-jms) compared to 200-300 messages per > second (with blueprint-based connectionfactory provider). > > I will investigate this and try to get a better picture of this problem, > following your suggestion. > > I will post back on this thread if I manage to get the results. > Sure - I'll be checking. > Thank you. > > and wish you a nice holiday :) > thanks! :) regards Grzegorz Grzybek > Regards, > Cooshal. > > On Wednesday, June 26, 2019 at 9:27:25 AM UTC+2, Grzegorz Grzybek wrote: >> >> Hello Kushal >> >> >> https://github.com/cooshal/karaf-assembly-jms/blob/DWH-PAX-JMS-Demo/datasources/broker-datasource/src/main/resources/config/org.ops4j.connectionfactory-activemq.cfg >> doesn't have any pooling configuration. >> >> on Monday I'm starting my deserved, 2 week holidays so I won't do much >> investigation now. >> >> If you believe the performance is worse with pax-jms, please try getting >> for example 1000 thread dumps every 100ms - if there are lot of threads >> waiting to acquire the connection, there may be pooling configuration >> problem. Generally a thread dump (set of dumps) can give you some clues. >> >> regards >> Grzegorz Grzybek >> >> śr., 26 cze 2019 o 08:07 Kushal Gautam <[email protected]> napisał(a): >> >>> Hi: >>> >>> sorry, took a bit longer than expected. Currently, I have switched to >>> blueprint based connectionfactory provider. The performance is much better >>> this way, as. >>> >>> I have implemented two scenarios, one with pax-jms based provider and >>> the other is blueprint based provider. >>> >>> pax-jms based provider: >>> https://github.com/cooshal/karaf-assembly-jms/tree/DWH-PAX-JMS-Demo >>> blueprint-based provider: >>> https://github.com/cooshal/karaf-assembly-jms/tree/DWH-Blueprint-JMS >>> >>> I created two different bundles with camel routes (one to produce a >>> message and the other to consume a message). The broker bundle (in both >>> cases) will provide two diff connection factories, i.e. eai-producer and >>> eai-consumer. I have used them in the camel routes respectively. >>> >>> While using pax-jms, I see just a single connection from the ActiveMQ >>> web console. In my example, I have given just one route. While, in my real >>> case scenario, I had multiple routes, and all of them were under the same >>> connection. >>> >>> My assumption was, there should have been at least two different >>> connections, as I had two different connection factories. >>> >>> I have added a docker-compose file for activemq broker. >>> >>> Kindly, please let me know if I need to explain the case further. >>> >>> Regards, >>> Cooshal. >>> >>> On Friday, June 21, 2019 at 3:33:26 PM UTC+2, Grzegorz Grzybek wrote: >>>> >>>> Hello >>>> >>>> my list of unread (unanswered) emails is too long ;) Please let me know >>>> when you add this branch with blueprint, so I can compare these two >>>> approaches. Then I'll continue the investigation of your case. >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> śr., 19 cze 2019 o 09:13 Kushal Gautam <[email protected]> >>>> napisał(a): >>>> >>>>> Hi: >>>>> >>>>> Sorry for the confusion, and mix-ups. >>>>> >>>>> Those were totally different approaches that I had tried. I will >>>>> explain what I did. >>>>> >>>>> 1. Initially, before trying out pax-jms, I was providing the broker >>>>> connectionfactory using blueprint, as I had mentioned earlier. This >>>>> approach was working fine enough, and then we decided to switch to >>>>> pax-jms. >>>>> 2. In the second scenario, the broker connectionfactory is entirely >>>>> provided by pax-jms. Blueprint is not used in this case. >>>>> >>>>> I have two connectionfactories, and I am using them as: >>>>> >>>>> <reference id="jmsConsumerConnectionFactory" >>>>> interface="javax.jms.ConnectionFactory" filter="( >>>>> osgi.jndi.service.name=jms/eai.consumer)" availability="mandatory" /> >>>>> <reference id="jmsProducerConnectionFactory" >>>>> interface="javax.jms.ConnectionFactory" filter="( >>>>> osgi.jndi.service.name=jms/eai.producer)" availability="mandatory" /> >>>>> >>>>> <bean id="eai-consumer" >>>>> class="org.apache.camel.component.jms.JmsComponent"> >>>>> <property name="connectionFactory" >>>>> ref="jmsConsumerConnectionFactory"/> >>>>> </bean> >>>>> >>>>> <bean id="eai-producer" >>>>> class="org.apache.camel.component.jms.JmsComponent"> >>>>> <property name="connectionFactory" >>>>> ref="jmsProducerConnectionFactory"/> >>>>> </bean> >>>>> >>>>> In both cases, I have set maxConnections to 20. Thus, with two >>>>> connectionFactories, I observed that, with pax-jms only 20 connections >>>>> were >>>>> there. While, with the blueprint approach, I could see 20(consumer) + >>>>> 20(producer) connections. >>>>> >>>>> and I am using this in my camel routes as: >>>>> >>>>> from("eai-consumer:queue:foo.xx.yy") ... >>>>> >>>>> I will share a project where this problem can be replicated. >>>>> >>>>> My pax-jms based approach is in this ( >>>>> https://github.com/cooshal/karaf-assembly-jms) project. I will update >>>>> this project later (on a different branch) with the blueprint based >>>>> approach as well. It does not have camel routes yet, I will add some camel >>>>> routes to demonstrate this issue. >>>>> >>>>> Regards, >>>>> Cooshal. >>>>> >>>>> >>>>> On Wednesday, June 19, 2019 at 8:01:19 AM UTC+2, Grzegorz Grzybek >>>>> wrote: >>>>>> >>>>>> Hello >>>>>> >>>>>> But as you wrote, you had this blueprint: >>>>>> >>>>>> <bean id="activemqConnectionFactory" >>>>>> class="org.apache.activemq.ActiveMQConnectionFactory"> >>>>>> <property name="brokerURL" value="${URL}" /> >>>>>> <property name="userName" value="${USERNAME}" /> >>>>>> <property name="password" value="${PASSWORD}" /> >>>>>> </bean> >>>>>> >>>>>> <bean id="consumerPooledConnectionFactory" >>>>>> class="org.apache.activemq.pool.PooledConnectionFactory"> >>>>>> <property name="maxConnections" value="${MAX_CONNECTIONS}" /> >>>>>> <property name="connectionFactory" >>>>>> ref="activemqConnectionFactory" /> >>>>>> </bean> >>>>>> ... >>>>>> <service ref="producerPooledConnectionFactory" >>>>>> interface="javax.jms.ConnectionFactory"> >>>>>> <service-properties> >>>>>> <entry key="name" value="producer" /> >>>>>> <entry key="osgi.jndi.service.name" >>>>>> value="${PRODUCER_JNDI_NAME}" /> >>>>>> </service-properties> >>>>>> </service> >>>>>> ... >>>>>> >>>>>> which means it's not related to pax-jms. But additionally you added >>>>>> pax-jms configuration (factory PID) that does one thing - checks OSGi >>>>>> services with javax.jms.ConnectionFactory interfaces (which is your >>>>>> org.apache.activemq.pool.PooledConnectionFactory) and wraps it again in >>>>>> the >>>>>> pooling connection factory. >>>>>> >>>>>> Can you share your entire project (before and after adding pax-jms)? >>>>>> >>>>>> regards >>>>>> Grzegorz Grzybek >>>>>> >>>>>> wt., 18 cze 2019 o 16:49 Kushal Gautam <[email protected]> >>>>>> napisał(a): >>>>>> >>>>>>> Hi: >>>>>>> >>>>>>> Here's what I have observed. >>>>>>> >>>>>>> If I provide the broker service by installing the broker bundle as >>>>>>> an artifact (using the blueprint configuration as I had shared before), >>>>>>> then there are altogether 41 connections(one is of Temp Advisory queue, >>>>>>> I >>>>>>> guess), because max-connections is set to 20 for producer and consumer >>>>>>> each. >>>>>>> >>>>>>> But, with pax-jms config, I observed that I have just 20 connections >>>>>>> (although I have set pool.maxConnections = 20) for both producer and >>>>>>> consumer. I guess, this could be the bottleneck of the performance. >>>>>>> >>>>>>> In both scenarios, the route bundles are same. Only the broker >>>>>>> service provider is diff. >>>>>>> >>>>>>> Regards, >>>>>>> Cooshal. >>>>>>> >>>>>>> >>>>>>> On Tuesday, June 18, 2019 at 4:09:24 PM UTC+2, Kushal Gautam wrote: >>>>>>>> >>>>>>>> I am using it like this: >>>>>>>> >>>>>>>> from("eai-consumer:queue:foo.xx.yy") >>>>>>>> ... >>>>>>>> ... >>>>>>>> >>>>>>>> Is there a performance lag for this as well ? >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, June 18, 2019 at 4:06:20 PM UTC+2, Jean-Baptiste Onofré >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Why don't you set the connection factory directly on the camel-jms >>>>>>>>> URI ? >>>>>>>>> >>>>>>>>> For instance: <from >>>>>>>>> uri="jms:queue:foo?connectionFactory=#jmsConsumerConnectionFactory"/> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> JB >>>>>>>>> On 18/06/2019 16:02, Kushal Gautam wrote: >>>>>>>>> >>>>>>>>> well, I am using them as: >>>>>>>>> >>>>>>>>> <reference id="jmsConsumerConnectionFactory" >>>>>>>>> interface="javax.jms.ConnectionFactory" filter="( >>>>>>>>> osgi.jndi.service.name=jms/eai.consumer)" >>>>>>>>> availability="mandatory" /> >>>>>>>>> <reference id="jmsProducerConnectionFactory" >>>>>>>>> interface="javax.jms.ConnectionFactory" filter="( >>>>>>>>> osgi.jndi.service.name=jms/eai.producer)" >>>>>>>>> availability="mandatory" /> >>>>>>>>> >>>>>>>>> <bean id="eai-consumer" >>>>>>>>> class="org.apache.camel.component.jms.JmsComponent"> >>>>>>>>> <property name="connectionFactory" >>>>>>>>> ref="jmsConsumerConnectionFactory"/> >>>>>>>>> </bean> >>>>>>>>> >>>>>>>>> <bean id="eai-producer" >>>>>>>>> class="org.apache.camel.component.jms.JmsComponent"> >>>>>>>>> <property name="connectionFactory" >>>>>>>>> ref="jmsProducerConnectionFactory"/> >>>>>>>>> </bean> >>>>>>>>> >>>>>>>>> On Tuesday, June 18, 2019 at 3:59:28 PM UTC+2, Jean-Baptiste >>>>>>>>> Onofré wrote: >>>>>>>>>> >>>>>>>>>> If you have two ConnectionFactory services, maybe you use only >>>>>>>>>> one service, that would explain why you only have one connection >>>>>>>>>> (with one >>>>>>>>>> producer and one consumer). >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> JB >>>>>>>>>> On 18/06/2019 15:52, Kushal Gautam wrote: >>>>>>>>>> >>>>>>>>>> Hi: >>>>>>>>>> >>>>>>>>>> ok. that's what I thought. >>>>>>>>>> >>>>>>>>>> So, here is my scenario. I have 4 karaf instances, and each >>>>>>>>>> instance has two pax-jms configurations(one for producer and one for >>>>>>>>>> consumer). But, in the connections tab, I see just one connection per >>>>>>>>>> instance. Is this a normal behavior? Because, I have two pax-jms >>>>>>>>>> configs >>>>>>>>>> and shldn't they have two connections per instance, in this case? I >>>>>>>>>> have to >>>>>>>>>> verify this thing with my previous implementation (while deploying >>>>>>>>>> broker >>>>>>>>>> as an artifact). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Cooshal. >>>>>>>>>> >>>>>>>>>> On Tuesday, June 18, 2019 at 3:45:41 PM UTC+2, Jean-Baptiste >>>>>>>>>> Onofré wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> That's the way JMS works. >>>>>>>>>>> >>>>>>>>>>> You create a ConnectionFactory. The connection factory provides >>>>>>>>>>> connections. >>>>>>>>>>> >>>>>>>>>>> A connection provides several sessions. A session is single >>>>>>>>>>> threaded, and "assigned" to an action (consume or produce). >>>>>>>>>>> >>>>>>>>>>> So, inside a single connection (for one client), you can have >>>>>>>>>>> bunch of sessions (some producing, some consuming). In Camel, you >>>>>>>>>>> can >>>>>>>>>>> define the number of sessions per connection. >>>>>>>>>>> >>>>>>>>>>> For consuming, you can use the receive() method or a >>>>>>>>>>> MessageListener. The session is also where you define the ACK mode >>>>>>>>>>> (AUTO, >>>>>>>>>>> CLIENT, DUPS, TRANSACTED). >>>>>>>>>>> >>>>>>>>>>> If you need more details, don't hesitate to ping me directly ;) >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> JB >>>>>>>>>>> On 18/06/2019 15:31, Kushal Gautam wrote: >>>>>>>>>>> >>>>>>>>>>> Hi again: >>>>>>>>>>> >>>>>>>>>>> I have a query on this issue. >>>>>>>>>>> >>>>>>>>>>> From the connections tab in the activemq webconsle, I see that >>>>>>>>>>> my hundreds of connections are reduced to very few connections. >>>>>>>>>>> That helped >>>>>>>>>>> me resolve some jms-error issues, where my packets were being >>>>>>>>>>> dropped >>>>>>>>>>> because my broker was overloaded. >>>>>>>>>>> >>>>>>>>>>> When I look at the details of the connection, I see multiple >>>>>>>>>>> consumer sessions. >>>>>>>>>>> >>>>>>>>>>> I am not able to comprehend the working method of this. Are all >>>>>>>>>>> these sessions using just one connection?? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Cooshal. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Monday, June 17, 2019 at 2:10:28 PM UTC+2, Grzegorz Grzybek >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello >>>>>>>>>>>> >>>>>>>>>>>> Hmm >>>>>>>>>>>> >>>>>>>>>>>> You wrote two similar blueprint files containing: >>>>>>>>>>>> >>>>>>>>>>>> <bean id="activemqConnectionFactory" >>>>>>>>>>>> class="org.apache.activemq.ActiveMQConnectionFactory"> >>>>>>>>>>>> <property name="brokerURL" value="${URL}" /> >>>>>>>>>>>> <property name="userName" value="${USERNAME}" /> >>>>>>>>>>>> <property name="password" value="${PASSWORD}" /> >>>>>>>>>>>> </bean> >>>>>>>>>>>> >>>>>>>>>>>> Having etc/org.ops4j.connectionfactory-producer.cfg doesn't >>>>>>>>>>>> affect your ActiveMQCOnnectionFactory + >>>>>>>>>>>> org.apache.activemq.pool.PooledConnectionFactory beans... >>>>>>>>>>>> >>>>>>>>>>>> With pax-jms, you should expose underlying connection >>>>>>>>>>>> javax.jms.ConnectionFactory OSGi service >>>>>>>>>>>> (ActiveMQConnectionFactory) >>>>>>>>>>>> without org.apache.activemq.pool.PooledConnectionFactory. >>>>>>>>>>>> >>>>>>>>>>>> Probably with pax-jms you have 3 layers: pooled-jms → >>>>>>>>>>>> PooledConnectionFactory → ActiveMQConnectionFactory. >>>>>>>>>>>> >>>>>>>>>>>> Now you don't need >>>>>>>>>>>> org.apache.activemq.pool.PooledConnectionFactory beans. >>>>>>>>>>>> >>>>>>>>>>>> regards >>>>>>>>>>>> Grzegorz Grzybek >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> pon., 17 cze 2019 o 13:05 Kushal Gautam <[email protected]> >>>>>>>>>>>> napisał(a): >>>>>>>>>>>> >>>>>>>>>>>>> Hi: >>>>>>>>>>>>> >>>>>>>>>>>>> this was my previous config: >>>>>>>>>>>>> >>>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?> >>>>>>>>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >>>>>>>>>>>>> xmlns:xsi=" >>>>>>>>>>>>> http://www.w3.org/2001/XMLSchema-instance"; >>>>>>>>>>>>> xmlns:cm=" >>>>>>>>>>>>> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0"; >>>>>>>>>>>>> xsi:schemaLocation=" >>>>>>>>>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0 >>>>>>>>>>>>> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd >>>>>>>>>>>>> >>>>>>>>>>>>> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.3.0 >>>>>>>>>>>>> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.3.0.xsd >>>>>>>>>>>>> "> >>>>>>>>>>>>> >>>>>>>>>>>>> <cm:property-placeholder persistent-id="prs-eai-broker" >>>>>>>>>>>>> update-strategy="reload" > >>>>>>>>>>>>> <cm:default-properties> >>>>>>>>>>>>> <cm:property name="URL" >>>>>>>>>>>>> value="tcp://localhost:61616" /> >>>>>>>>>>>>> <cm:property name="USERNAME" value="system" /> >>>>>>>>>>>>> <cm:property name="PASSWORD" value="manager" /> >>>>>>>>>>>>> <cm:property name="MAX_CONNECTIONS" value="20" /> >>>>>>>>>>>>> <cm:property name="PRODUCER_JNDI_NAME" >>>>>>>>>>>>> value="jms/producer" /> >>>>>>>>>>>>> <cm:property name="CONSUMER_JNDI_NAME" >>>>>>>>>>>>> value="jms/consumer" /> >>>>>>>>>>>>> </cm:default-properties> >>>>>>>>>>>>> </cm:property-placeholder> >>>>>>>>>>>>> >>>>>>>>>>>>> <bean id="activemqConnectionFactory" >>>>>>>>>>>>> class="org.apache.activemq.ActiveMQConnectionFactory"> >>>>>>>>>>>>> <property name="brokerURL" value="${URL}" /> >>>>>>>>>>>>> <property name="userName" value="${USERNAME}" /> >>>>>>>>>>>>> <property name="password" value="${PASSWORD}" /> >>>>>>>>>>>>> </bean> >>>>>>>>>>>>> >>>>>>>>>>>>> <bean id="consumerPooledConnectionFactory" >>>>>>>>>>>>> class="org.apache.activemq.pool.PooledConnectionFactory"> >>>>>>>>>>>>> <property name="maxConnections" >>>>>>>>>>>>> value="${MAX_CONNECTIONS}" /> >>>>>>>>>>>>> <property name="connectionFactory" >>>>>>>>>>>>> ref="activemqConnectionFactory" /> >>>>>>>>>>>>> </bean> >>>>>>>>>>>>> >>>>>>>>>>>>> <bean id="producerPooledConnectionFactory" >>>>>>>>>>>>> class="org.apache.activemq.pool.PooledConnectionFactory"> >>>>>>>>>>>>> <property name="maxConnections" >>>>>>>>>>>>> value="${MAX_CONNECTIONS}" /> >>>>>>>>>>>>> <property name="connectionFactory" >>>>>>>>>>>>> ref="activemqConnectionFactory" /> >>>>>>>>>>>>> </bean> >>>>>>>>>>>>> >>>>>>>>>>>>> <service ref="producerPooledConnectionFactory" >>>>>>>>>>>>> interface="javax.jms.ConnectionFactory"> >>>>>>>>>>>>> <service-properties> >>>>>>>>>>>>> <entry key="name" value="producer" /> >>>>>>>>>>>>> <entry key="osgi.jndi.service.name" >>>>>>>>>>>>> value="${PRODUCER_JNDI_NAME}" /> >>>>>>>>>>>>> </service-properties> >>>>>>>>>>>>> </service> >>>>>>>>>>>>> >>>>>>>>>>>>> <service ref="consumerPooledConnectionFactory" >>>>>>>>>>>>> interface="javax.jms.ConnectionFactory"> >>>>>>>>>>>>> <service-properties> >>>>>>>>>>>>> <entry key="name" value="consumer" /> >>>>>>>>>>>>> <entry key="osgi.jndi.service.name" >>>>>>>>>>>>> value="${CONSUMER_JNDI_NAME}" /> >>>>>>>>>>>>> </service-properties> >>>>>>>>>>>>> </service> >>>>>>>>>>>>> >>>>>>>>>>>>> </blueprint> >>>>>>>>>>>>> >>>>>>>>>>>>> I will try to see if I can get the stack trace. This problem >>>>>>>>>>>>> is currently there in the prod. system. So, I have to check that >>>>>>>>>>>>> once. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Cooshal. >>>>>>>>>>>>> >>>>>>>>>>>>> On Monday, June 17, 2019 at 12:20:52 PM UTC+2, Grzegorz >>>>>>>>>>>>> Grzybek wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello >>>>>>>>>>>>>> >>>>>>>>>>>>>> What was your previous configuration? Is there a chance to >>>>>>>>>>>>>> get a stack trace from under the debugger in the place where >>>>>>>>>>>>>> message is put >>>>>>>>>>>>>> into queue? >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards >>>>>>>>>>>>>> Grzegorz Grzybek >>>>>>>>>>>>>> >>>>>>>>>>>>>> pon., 17 cze 2019 o 12:11 Kushal Gautam <[email protected]> >>>>>>>>>>>>>> napisał(a): >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently, I am observing some lag in putting the messages >>>>>>>>>>>>>>> in one of the queues. Roughly, the number is about 1-4 messages >>>>>>>>>>>>>>> per second. >>>>>>>>>>>>>>> And, this is way too slow than my previous configuration. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I checked this from the activemq console. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will try to see if I can produce some performance metrics. >>>>>>>>>>>>>>> But, the thing is that I observed the enqueue/dequeue rates to >>>>>>>>>>>>>>> be extremely >>>>>>>>>>>>>>> slow. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Cooshal. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Monday, June 17, 2019 at 11:02:40 AM UTC+2, Grzegorz >>>>>>>>>>>>>>> Grzybek wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What kind of processing performance problems do you have? >>>>>>>>>>>>>>>> pax-jms doesn't add any special processing - it only deals >>>>>>>>>>>>>>>> with exposing >>>>>>>>>>>>>>>> connection factories to your beans/components/services/... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PooledJMS itself MAY add some processing overhead, but it >>>>>>>>>>>>>>>> of course depends on its configuration. After your application >>>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>>> javax.jms.ConnectionFactory.getConnection(), it's all up to >>>>>>>>>>>>>>>> you/camel-jms/spring-jms how to use/cache/not-cache it... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm interested in some numbers, logs maybe - how did you >>>>>>>>>>>>>>>> find out that the performance is worse? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks in advance for any help/feedback >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>> Grzegorz Grzybek >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> pon., 17 cze 2019 o 10:57 Kushal Gautam < >>>>>>>>>>>>>>>> [email protected]> napisał(a): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am using Camel with Karaf, and ActiveMQ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Before using pax-jms, I was providing connectionfactories >>>>>>>>>>>>>>>>> as artifact. But, since it was not configurable, I planned to >>>>>>>>>>>>>>>>> switch it to >>>>>>>>>>>>>>>>> pax-jms. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But, so far, after switching to pax-jms, I have noticed >>>>>>>>>>>>>>>>> performance lag in message processing. I am not entirely >>>>>>>>>>>>>>>>> sure, if this is >>>>>>>>>>>>>>>>> due to pax-jms. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thus, in general, does pax-jms degrade the message >>>>>>>>>>>>>>>>> processing performance at all? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example, my jms-config looks like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> name = eai-producer >>>>>>>>>>>>>>>>> jms.url = tcp://localhost:61616 >>>>>>>>>>>>>>>>> jms.username = system >>>>>>>>>>>>>>>>> jms.password = manager >>>>>>>>>>>>>>>>> type = activemq >>>>>>>>>>>>>>>>> pool = pooledjms >>>>>>>>>>>>>>>>> osgi.jndi.service.name = jms/producer >>>>>>>>>>>>>>>>> org.apache.karaf.features.configKey = >>>>>>>>>>>>>>>>> org.ops4j.connectionfactory-producer >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Cooshal. >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> ------------------ >>>>>>>>>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> You received this message because you are subscribed to >>>>>>>>>>>>>>>>> the Google Groups "OPS4J" group. >>>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails >>>>>>>>>>>>>>>>> from it, send an email to [email protected]. >>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/ops4j/dc425a85-23d9-4f47-a855-9d9d96a70689%40googlegroups.com >>>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/dc425a85-23d9-4f47-a855-9d9d96a70689%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> ------------------ >>>>>>>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails >>>>>>>>>>>>>>> from it, send an email to [email protected]. >>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/d/msgid/ops4j/3c8d060e-8f7b-4c47-aee3-1b955d217aef%40googlegroups.com >>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/3c8d060e-8f7b-4c47-aee3-1b955d217aef%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> -- >>>>>>>>>>>>> ------------------ >>>>>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/ops4j/13c998f7-3dc2-4a5e-b894-8622ce1dbad4%40googlegroups.com >>>>>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/13c998f7-3dc2-4a5e-b894-8622ce1dbad4%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> -- >>>>>>>>>>> ------------------ >>>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/ops4j/0f4804ab-4425-4a3d-a830-4d021f07422f%40googlegroups.com >>>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/0f4804ab-4425-4a3d-a830-4d021f07422f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> ------------------ >>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/ops4j/f44f861b-9793-4155-af05-57a60182c5a4%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/f44f861b-9793-4155-af05-57a60182c5a4%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> ------------------ >>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>> >>>>>>>>> --- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "OPS4J" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/ops4j/67d50e80-2975-4db6-b999-7a93066d0aaf%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/ops4j/67d50e80-2975-4db6-b999-7a93066d0aaf%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>>> -- >>>>>>> -- >>>>>>> ------------------ >>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "OPS4J" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/ops4j/5cf80056-ba28-4ede-acb8-e704e1460ebe%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/ops4j/5cf80056-ba28-4ede-acb8-e704e1460ebe%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OPS4J" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ops4j/c2367cf3-3cf6-4eca-ac4d-da340eed8273%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ops4j/c2367cf3-3cf6-4eca-ac4d-da340eed8273%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - [email protected] >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ops4j/a021ebc8-3de4-4e89-b7e2-beb318d8a961%40googlegroups.com >>> <https://groups.google.com/d/msgid/ops4j/a021ebc8-3de4-4e89-b7e2-beb318d8a961%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/b608ac0c-1125-42fc-9f09-602a65a1d0e3%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/b608ac0c-1125-42fc-9f09-602a65a1d0e3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhpBx8-MskTZAe8NwWdJSKk0H4Uv8PLN8C13oSKxrqSm3g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
