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 <daniel.no...@dz-privatbank.com> 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 just misunderstood something it would be great if you could help me out
> with this one.
>
>
> Best regards and thanks a lot in advance,
> Daniel Novak
>
>
> **********************************************************************
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> please call or e-mail the sender and delete the message and any attachment
> from your system. If you are not the intended recipient, you must not copy
> this message or attachment or disclose the contents to any other person.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive later or
> incomplete, or contain viruses. DZ PRIVATBANK therefore does not accept
> liability for any errors or omissions in the contents of this message which
> arises as a result of e-mail transmission. If verification is required please
> request a hard-copy version. This message is provided for informational
> purposes only and should not be construed as a solicitation or offer to buy
> or sell any securities or related financial instruments. DZ PRIVATBANK does
> not warrant that incoming e-mails will be processed within a certain period
> of time. For security reasons, DZ PRIVATBANK does not accept any instructions
> that must be in writing (financial transactions, changes of address, etc.)
> sent by e-mail. If a message is urgent, please contact us by telephone.
> **********************************************************************
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
