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/CAAdXmhqKQe9qnVn2Fm8j4vLu3x-%3D%3D8gwwYZErzYoXLOW0hkf7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
