Re: Definition of subscriptionname in Camel JMS-Endpoint does not work as expected
Please ignore, sent to wrong list :-) Am 15.08.2019 um 12:59 schrieb Benjamin Graf: > Hi all together, > > just to keep the list informed. Issue is documented and fixed with > https://issues.apache.org/jira/browse/CAMEL-13864. > > Regards > > Benjamin > > Am 13.08.2019 um 16:37 schrieb Benjamin Graf: >> Hi Claus, >> >> Sure ;-) >> >> Will have a look on it. I might create a patch on actual master. I think a >> backport to 2.x branch shouldn't be that hard. >> >> Regards >> Benjamin >> >> Gesendet: Dienstag, 13. August 2019 um 15:57 Uhr >> Von: "Claus Ibsen" >> An: us...@camel.apache.org >> Betreff: Re: Re: Definition of subscriptionname in Camel JMS-Endpoint does >> not work as expected >> On Tue, Aug 13, 2019 at 2:50 PM Benjamin Graf wrote: >>> Hi, >>> >>> yes it seems non-durable shared subscription are not implemented correctly. >>> Subscription name should be set for non-durable as well. >>> >> Okay you are welcome to create a JIRA ticket and also PRs is welcome to fix >> this >> >>> Regards >>> Benjamin >>> >>> >>> Gesendet: Dienstag, 13. August 2019 um 11:57 Uhr >>> Von: "Claus Ibsen" >>> An: us...@camel.apache.org >>> Betreff: Re: Definition of subscriptionname in Camel JMS-Endpoint does not >>> work as expected >>> Hi >>> >>> Shared subscription is something new in JMS 2.0. >>> So it may be a bug or not, I can't recall on top of my head. I suggest >>> you spend a bit time research and come back and tell us. >>> >>> On Tue, Aug 13, 2019 at 11:46 AM wrote: >>>> Dear Camel guys and girls, >>>> >>>> >>>> I have a question regarding the property "subscriptionName" which can be >>>> specified for a JMS-Consumer. >>>> >>>> First, here is my project setup: >>>> >>>> * Camel 2.24.1 >>>> * Spring-Boot: 2.1.0.RELEASE >>>> >>>> I create a simple standalone JAR which just should consume from defined >>>> JMS-Queues and/or JMS-Topics. >>>> Therefore I wrote a simple Route and configured my JMS-Endpoint like this: >>>> >>>> jms:topic:mytopicstring?connectionFactory=#connectionFactory&defaultTaskExecutorType=SimpleAsync&bridgeErrorHandler=true&subscriptionShared=true&subscriptionName=jmsc_lokal >>>> >>>> As you can see I use a shared subscription in combination with a >>>> subscriptionName as I want to be able to identify my subscription as long >>>> as it lasts. >>>> The problem is now that this subscriptionName is never used. Instead my >>>> subscription on the topic uses the default subscription name which is the >>>> class name: org.apache.camel.component.jms.EndpointMessageListener. >>>> >>>> In the documentation on GitHub for Camel Version 2.24.1 it is written that >>>> the subscriptionName can be used for shared subscription too.: >>>> >>>> >>>> subscriptionName (consumer) >>>> >>>> >>>> Set the name of a subscription to create. To be applied in case of a topic >>>> (pub-sub domain) with a shared or durable subscription. The subscription >>>> name needs to be unique within this client’s JMS client id. Default is the >>>> class name of the specified message listener. Note: Only 1 concurrent >>>> consumer (which is the default of this message listener container) is >>>> allowed for each subscription, except for a shared subscription (which >>>> requires JMS 2.0). >>>> >>>> >>>> If I debug into the method >>>> org.apache.camel.component.jms.JmsEndpoint#configureListenerContainer >>>> I can see that the subscriptionName is in fact only used when the >>>> subscription is durable (which I don't want to have): >>>> >>>> >>>> // now configure the JMS 2.0 API >>>> if (configuration.getDurableSubscriptionName() != null) { >>>> listenerContainer.setDurableSubscriptionName(configuration.getDurableSubscriptionName()); >>>> } else if (configuration.isSubscriptionDurable()) { >>>> listenerContainer.setSubscriptionDurable(true); >>>> if (configuration.getSubscriptionName() != null) { >>>> listenerContainer.setSubscriptionName(configuration.getSubscriptionName()); >>>>
Re: Definition of subscriptionname in Camel JMS-Endpoint does not work as expected
Hi all together, just to keep the list informed. Issue is documented and fixed with https://issues.apache.org/jira/browse/CAMEL-13864. Regards Benjamin Am 13.08.2019 um 16:37 schrieb Benjamin Graf: > Hi Claus, > > Sure ;-) > > Will have a look on it. I might create a patch on actual master. I think a > backport to 2.x branch shouldn't be that hard. > > Regards > Benjamin > > Gesendet: Dienstag, 13. August 2019 um 15:57 Uhr > Von: "Claus Ibsen" > An: us...@camel.apache.org > Betreff: Re: Re: Definition of subscriptionname in Camel JMS-Endpoint does > not work as expected > On Tue, Aug 13, 2019 at 2:50 PM Benjamin Graf wrote: >> Hi, >> >> yes it seems non-durable shared subscription are not implemented correctly. >> Subscription name should be set for non-durable as well. >> > Okay you are welcome to create a JIRA ticket and also PRs is welcome to fix > this > >> Regards >> Benjamin >> >> >> Gesendet: Dienstag, 13. August 2019 um 11:57 Uhr >> Von: "Claus Ibsen" >> An: us...@camel.apache.org >> Betreff: Re: Definition of subscriptionname in Camel JMS-Endpoint does not >> work as expected >> Hi >> >> Shared subscription is something new in JMS 2.0. >> So it may be a bug or not, I can't recall on top of my head. I suggest >> you spend a bit time research and come back and tell us. >> >> On Tue, Aug 13, 2019 at 11:46 AM wrote: >>> Dear Camel guys and girls, >>> >>> >>> I have a question regarding the property "subscriptionName" which can be >>> specified for a JMS-Consumer. >>> >>> First, here is my project setup: >>> >>> * Camel 2.24.1 >>> * Spring-Boot: 2.1.0.RELEASE >>> >>> I create a simple standalone JAR which just should consume from defined >>> JMS-Queues and/or JMS-Topics. >>> Therefore I wrote a simple Route and configured my JMS-Endpoint like this: >>> >>> jms:topic:mytopicstring?connectionFactory=#connectionFactory&defaultTaskExecutorType=SimpleAsync&bridgeErrorHandler=true&subscriptionShared=true&subscriptionName=jmsc_lokal >>> >>> As you can see I use a shared subscription in combination with a >>> subscriptionName as I want to be able to identify my subscription as long >>> as it lasts. >>> The problem is now that this subscriptionName is never used. Instead my >>> subscription on the topic uses the default subscription name which is the >>> class name: org.apache.camel.component.jms.EndpointMessageListener. >>> >>> In the documentation on GitHub for Camel Version 2.24.1 it is written that >>> the subscriptionName can be used for shared subscription too.: >>> >>> >>> subscriptionName (consumer) >>> >>> >>> Set the name of a subscription to create. To be applied in case of a topic >>> (pub-sub domain) with a shared or durable subscription. The subscription >>> name needs to be unique within this client’s JMS client id. Default is the >>> class name of the specified message listener. Note: Only 1 concurrent >>> consumer (which is the default of this message listener container) is >>> allowed for each subscription, except for a shared subscription (which >>> requires JMS 2.0). >>> >>> >>> If I debug into the method >>> org.apache.camel.component.jms.JmsEndpoint#configureListenerContainer >>> I can see that the subscriptionName is in fact only used when the >>> subscription is durable (which I don't want to have): >>> >>> >>> // now configure the JMS 2.0 API >>> if (configuration.getDurableSubscriptionName() != null) { >>> listenerContainer.setDurableSubscriptionName(configuration.getDurableSubscriptionName()); >>> } else if (configuration.isSubscriptionDurable()) { >>> listenerContainer.setSubscriptionDurable(true); >>> if (configuration.getSubscriptionName() != null) { >>> listenerContainer.setSubscriptionName(configuration.getSubscriptionName()); >>> } >>> } >>> listenerContainer.setSubscriptionShared(configuration.isSubscriptionShared()); >>> >>> So I am wondering if I just misunderstood the documentation or if it is >>> indeed a bug that the subscriptionName can only be used in combination with >>> a durable subscription? >>> Could you please tell me what you think? >>> >>> If it is a bug I can create a JIRA-Issue and provide a hotfix if you want. >>> If I j