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
