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. Thank you. and wish you a nice holiday :) 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] <javascript:>> > 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] <javascript:> >> >> --- >> 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] <javascript:>. >> 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. For more options, visit https://groups.google.com/d/optout.
