jms-spec
  1. jms-spec
  2. JMS_SPEC-65

Clarify use of NoLocal arg when using createDurableSubscriber

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 2.0ED, 2.0
    • Labels:
      None

      Description

      This issue relates to the following method on javax.jms.Session:

      TopicSubscriber createDurableSubscriber(Topic topic,
                                              java.lang.String name,
                                              java.lang.String messageSelector,
                                              boolean noLocal)
                                              throws JMSException
      
      

      What does noLocal mean in this context? The javadoc states that this method "Creates a durable subscriber to the specified topic, using a message selector and specifying whether messages published by its own connection should be delivered to it". However it is ambiguous whether "it" refers to the durable subscription in the JMS provider or the TopicSubscriber object.

      Does noLocal mean
      (1) that messages published by this connection should not be added to the durable subscription, or that
      (2) messages published by this connection should not be delivered to this particular TopicSubscriber? These do not mean the same thing, since in the latter case the messages might be saved in the subscription and delivered at some later stage.

      This should be clarified.

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment - - edited

          This change (and this whole issue) concerns durable subscriptions only, and was intended to clarify what the existing JMS 1.1 behaviour should be.

          The definition of noLocal for non-durable, non-shared subscriptions is unchanged from JMS 1.1. In that case client identifier may be either set or unset when noLocal is true. If a message is sent by the same Connection object which created the subscription then the message will not be added to the subscription. No need to rely on UUID, since when the connection that created the subscription is closed, the subscription will be deleted.

          The introduction of shared durable and non-durable subscriptions in JMS 2.0 does introduce the issue of what noLocal means in that case. I will raise this as part of issue JMS_SPEC-40 which covers shared durable and non-durable subscriptions.

          Show
          Nigel Deakin added a comment - - edited This change (and this whole issue) concerns durable subscriptions only, and was intended to clarify what the existing JMS 1.1 behaviour should be. The definition of noLocal for non-durable, non-shared subscriptions is unchanged from JMS 1.1. In that case client identifier may be either set or unset when noLocal is true. If a message is sent by the same Connection object which created the subscription then the message will not be added to the subscription. No need to rely on UUID, since when the connection that created the subscription is closed, the subscription will be deleted. The introduction of shared durable and non-durable subscriptions in JMS 2.0 does introduce the issue of what noLocal means in that case. I will raise this as part of issue JMS_SPEC-40 which covers shared durable and non-durable subscriptions.
          Hide
          clebertsuconic added a comment -

          My bad .. this is is certainly only about durable subscription

          I'm happy with what you propose then.. but as I told you in a private email I prefer some exception as opposed to just ignore it.

          Show
          clebertsuconic added a comment - My bad .. this is is certainly only about durable subscription I'm happy with what you propose then.. but as I told you in a private email I prefer some exception as opposed to just ignore it.
          Hide
          chris.barrow added a comment - - edited

          Sorry to eat my words here, but in light of the discussion about non-durables I would now recommend changing the behavior for createDurableSubscription with noLocal=true to make it independent of clientID and consistent with non-durable shared consumers. See my recent comment in JMS_SPEC_40.

          Show
          chris.barrow added a comment - - edited Sorry to eat my words here, but in light of the discussion about non-durables I would now recommend changing the behavior for createDurableSubscription with noLocal=true to make it independent of clientID and consistent with non-durable shared consumers. See my recent comment in JMS_SPEC_40 .
          Hide
          clebertsuconic added a comment -

          @chriss: you need some sort of client-id to replay the queues and do the correct association.

          Most implementations I know will use an internal filter on the queue with message.originatingID != currentID.

          how would you replay the queue on these circunstances? what about previous sent messages?

          Show
          clebertsuconic added a comment - @chriss: you need some sort of client-id to replay the queues and do the correct association. Most implementations I know will use an internal filter on the queue with message.originatingID != currentID. how would you replay the queue on these circunstances? what about previous sent messages?
          Hide
          Nigel Deakin added a comment -

          This issue is resolved in the JMS 2.0 final release. Marking issue as resolved with a "fix version" of 2.0

          Show
          Nigel Deakin added a comment - This issue is resolved in the JMS 2.0 final release. Marking issue as resolved with a "fix version" of 2.0

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              Nigel Deakin
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: