jms-spec
  1. jms-spec
  2. JMS_SPEC-40

Allow multiple consumers to be created on the same topic subscription

    Details

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

      Description

      This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

      The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

      Durable subscriptions

      For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

      This affects the following JMS existing JMS 2.1 methods on Session (and its subtypes QueueSession, TopicSession, XASession, XAQueueSession and XATopicSession):

      createDurableSubscriber(Topic topic, String name)
      createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal) 
      

      It also affects the following JMS new JMS 2.0 methods on Session (and its subtypes QueueSession, TopicSession, XASession, XAQueueSession and XATopicSession) (added in JIRA issue 51 ):

      createDurableConsumer(Topic topic, String name)
      createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
      

      And in the new JMS 2.0 simplified API, it also affects the following method on JMSContext:

      createDurableConsumer(Topic topic, String name)
      createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
      

      All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

      No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

      By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.

      This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

      However in JMS 2.0, clientId will become optional when creating a durable subscription (see JIRA issue 39). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

      This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

      In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for Session.createDurableSubscriber):

      A client can change an existing durable subscription by creating a durable TopicSubscriber with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.

      This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a JMSException will be thrown (in the case of JMSContext a JMSRuntimeException will be thrown).

      The semantics for the unsubscribe methods on Session and JMSContext would remain unchanged. The javadocs state that "It is erroneous for a client to delete a durable subscription while there is an active MessageConsumer or TopicSubscriber for the subscription". This will continue to be the case.

      Non-durable subscriptions

      For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

      To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same sharedSubscriptionName.

      The following new methods on Session (and its subtypes) are proposed:

      MessageConsumer createSharedConsumer(
         Topic topic, String sharedSubscriptionName);
      MessageConsumer createSharedConsumer(
         Destination destination, String sharedSubscriptionName, String messageSelector)
      MessageConsumer createSharedConsumer(
         Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
      

      Note that if these methods were called simply createConsumer there would be a clash with the existing method createConsumer(Destination destination, String messageSelector). Note that these methods take a Topic, not a Destination.

      In the new simplified API, the following new methods on JMSContext are proposed:

      JMSConsumer createSharedConsumer(
         Topic topic, String sharedSubscriptionName)
      JMSConsumer createSharedConsumer(
         Topic topic, String sharedSubscriptionName, String messageSelector)
      JMSConsumer createSharedConsumer(
         Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
      

      Note that a given shared subscription does not exist if there are no consumers using it.

        Issue Links

          Activity

          Nigel Deakin created issue -
          Nigel Deakin made changes -
          Field Original Value New Value
          Affects Version/s 1.1 [ 14685 ]
          Nigel Deakin made changes -
          Summary Allow multiple threads in same client to consume messages from the same topic subscription Allow multiple consumers to be created on the same topic subscription
          Description This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

          This proposal would allow multiple threads in the same client to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple threads in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.

          The normal restrictions on the use of a session by multiple threads would continue to apply.

          For durable subscriptions, there would be no need to change the existing API. However it would be necessary to relax the existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName, for th elimited case where the same connection is used:
          {noformat}TopicSubscriber topicSubscriber1 = topicSession.createDurableSubscriber(topic,durableSubscriptionName);
          MessageListener listener1 = new TheListener();
          topicSubscriber1.setMessageListener(listener1);

          TopicSubscriber topicSubscriber2 = topicSession.createDurableSubscriber(topic,durableSubscriptionName);
          MessageListener listener2 = new TheListener();
          topicSubscriber2.setMessageListener(listener2);
          {noformat}

          For non-durable subscriptions, the existing JMS API already specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created. A new API would be needed for this new case when two non-durable TopicSubscribers share the same subscription.

          {noformat}TopicSubscriber topicSubscriber1 = topicSession.createSharedSubscriber(topic,sharedSubscriptionName);
          MessageListener listener1 = new TheListener();
          topicSubscriber1.setMessageListener(listener1);

          TopicSubscriber topicSubscriber2 = topicSession.createSharedSubscriber(topic,sharedSubscriptionName);
          MessageListener listener2 = new TheListener();
          topicSubscriber2.setMessageListener(listener2);
          {noformat}

          It is intended that the ability to create multiple TopicSubscribers on the same subscription be limited to the same connection.

          The above is not intended to a definitive description of this feature or its API, but is intended to illustrate the requirement.

          This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          For *durable subscriptions*, there would be no need to change the existing API. However it would be necessary to relax the existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:

          {noformat}TopicSubscriber topicSubscriber1 =
             topicSession.createDurableSubscriber(topic,durableSubscriptionName);
          {noformat}

          This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39], but that the existing requirement for clientId to be unique to remain.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          For *non-durable subscriptions*, the existing JMS API already specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created. A new API would be needed for this new case when it is desired that two non-durable TopicSubscribers share the same subscription, which would be identified by a new sharedSubscriptionName:

          {noformat}TopicSubscriber topicSubscriber1 =
             topicSession.createSharedSubscriber(topic,sharedSubscriptionName);
          {noformat}


          Status Whiteboard Summary changed from "Allow multiple threads in same client to consume messages from the same topic subscription" to "Allow multiple consumers to be created on the same topic subscription", and description amended accordingly.
          Nigel Deakin made changes -
          Description This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          For *durable subscriptions*, there would be no need to change the existing API. However it would be necessary to relax the existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:

          {noformat}TopicSubscriber topicSubscriber1 =
             topicSession.createDurableSubscriber(topic,durableSubscriptionName);
          {noformat}

          This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39], but that the existing requirement for clientId to be unique to remain.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          For *non-durable subscriptions*, the existing JMS API already specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created. A new API would be needed for this new case when it is desired that two non-durable TopicSubscribers share the same subscription, which would be identified by a new sharedSubscriptionName:

          {noformat}TopicSubscriber topicSubscriber1 =
             topicSession.createSharedSubscriber(topic,sharedSubscriptionName);
          {noformat}


          This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          For *durable subscriptions*, there would be no need to change the existing API. However it would be necessary to relax the existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:

          Assuming the new method proposed in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51], this would be:

          {noformat}
          session.createDurableConsumer(topic,durableSubscriptionName)
          {noformat}

          This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39], but that the existing requirement for clientId to be unique to remain.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          For *non-durable subscriptions*, the existing JMS API already specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created. A new API would be needed for this new case when it is desired that two non-durable subscribers share the same subscription, which would be identified by a new sharedSubscriptionName.

          {noformat}MessageConsumer messageConsumer=
             session.createSharedConsumer(topic,sharedSubscriptionName);
          {noformat}

          (Since [JIRA issue 47 | http://java.net/jira/browse/JMS_SPEC-47] proposes that {{TopicSession}} be deprecated, no change to that interface is proposed)


           

          Nigel Deakin made changes -
          Status Whiteboard Summary changed from "Allow multiple threads in same client to consume messages from the same topic subscription" to "Allow multiple consumers to be created on the same topic subscription", and description amended accordingly.
          Nigel Deakin made changes -
          Tags eg eg prd-planned
          Nigel Deakin made changes -
          Tags eg prd-planned eg pd20-planned prd-planned
          Nigel Deakin made changes -
          Tags eg pd20-planned prd-planned eg pd20-planned
          Nigel Deakin made changes -
          Tags eg pd20-planned eg
          Nigel Deakin made changes -
          Tags eg eg pd20-underreview
          Nigel Deakin made changes -
          Link This issue is duplicated by JMS_SPEC-23 [ JMS_SPEC-23 ]
          Nigel Deakin made changes -
          Description This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          For *durable subscriptions*, there would be no need to change the existing API. However it would be necessary to relax the existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:

          Assuming the new method proposed in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51], this would be:

          {noformat}
          session.createDurableConsumer(topic,durableSubscriptionName)
          {noformat}

          This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39], but that the existing requirement for clientId to be unique to remain.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          For *non-durable subscriptions*, the existing JMS API already specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created. A new API would be needed for this new case when it is desired that two non-durable subscribers share the same subscription, which would be identified by a new sharedSubscriptionName.

          {noformat}MessageConsumer messageConsumer=
             session.createSharedConsumer(topic,sharedSubscriptionName);
          {noformat}

          (Since [JIRA issue 47 | http://java.net/jira/browse/JMS_SPEC-47] proposes that {{TopicSession}} be deprecated, no change to that interface is proposed)


           

          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          h4.Durable subscriptions

          For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

          This affects the following JMS existing JMS 2.1 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}):

          {noformat}
          createDurableSubscriber(Topic topic, String name)
          createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          It also affects the following JMS new JMS 2.0 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}) (added in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]):

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          And in the new JMS 2.0 simplified API, it also affects the following method on {{JMSContext}}:

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

          No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

          {quote}
          By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.
          {quote}

          This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

          However in JMS 2.0, clientId will become optional when creating a durable subscription (see [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39]). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for {{Session.createDurableSubscriber}}):

          {quote}
          A client can change an existing durable subscription by creating a durable {{TopicSubscriber}} with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.
          {quote}

          This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a {{JMSException}} will be thrown (in the case of {{JMSContext}} a {{JMSRuntimeException}} will be thrown).

          h4.Non-durable subscriptions

          For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

          To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same {{sharedSubscriptionName}}.

          The following new methods on {{Session}} (and its subtypes) are proposed:

          {noformat}
          MessageConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName);
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector)
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
          {noformat}

          Note that if these methods were called simply {{createConsumer}} there would be a clash with the existing method {createConsumer(Destination destination, String messageSelector)}}. Note that these methods take a {{Topic}}, not a {{Destination}}.

          In the new simplified API, the following new methods on {{JMSContext}} are proposed:

          {noformat}
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
          {noformat}

          Note that a given shared subscription does not exist if there are no consumers using it.
                  
          Nigel Deakin made changes -
          Link This issue depends on JMS_SPEC-93 [ JMS_SPEC-93 ]
          Nigel Deakin made changes -
          Comment [ Summary changed from "Allow multiple threads in same client to consume messages from the same topic subscription" to "Allow multiple consumers to be created on the same topic subscription", and description amended accordingly.

          Further updated to remove references to the domain-specific interfaces such as {{TopicSession}} which [JIRA issue 47 | http://java.net/jira/browse/JMS_SPEC-47] proposes to deprecate, and replace them with appropriate methods on {{Session}}, including the new {{createDurableCOnsumer}} method proposed in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]. ]
          Nigel Deakin made changes -
          Description This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          h4.Durable subscriptions

          For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

          This affects the following JMS existing JMS 2.1 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}):

          {noformat}
          createDurableSubscriber(Topic topic, String name)
          createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          It also affects the following JMS new JMS 2.0 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}) (added in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]):

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          And in the new JMS 2.0 simplified API, it also affects the following method on {{JMSContext}}:

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

          No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

          {quote}
          By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.
          {quote}

          This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

          However in JMS 2.0, clientId will become optional when creating a durable subscription (see [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39]). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for {{Session.createDurableSubscriber}}):

          {quote}
          A client can change an existing durable subscription by creating a durable {{TopicSubscriber}} with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.
          {quote}

          This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a {{JMSException}} will be thrown (in the case of {{JMSContext}} a {{JMSRuntimeException}} will be thrown).

          h4.Non-durable subscriptions

          For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

          To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same {{sharedSubscriptionName}}.

          The following new methods on {{Session}} (and its subtypes) are proposed:

          {noformat}
          MessageConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName);
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector)
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
          {noformat}

          Note that if these methods were called simply {{createConsumer}} there would be a clash with the existing method {createConsumer(Destination destination, String messageSelector)}}. Note that these methods take a {{Topic}}, not a {{Destination}}.

          In the new simplified API, the following new methods on {{JMSContext}} are proposed:

          {noformat}
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
          {noformat}

          Note that a given shared subscription does not exist if there are no consumers using it.
                  
          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          h4.Durable subscriptions

          For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

          This affects the following JMS existing JMS 2.1 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}):

          {noformat}
          createDurableSubscriber(Topic topic, String name)
          createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          It also affects the following JMS new JMS 2.0 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}) (added in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]):

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          And in the new JMS 2.0 simplified API, it also affects the following method on {{JMSContext}}:

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

          No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

          {quote}
          By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.
          {quote}

          This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

          However in JMS 2.0, clientId will become optional when creating a durable subscription (see [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39]). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for {{Session.createDurableSubscriber}}):

          {quote}
          A client can change an existing durable subscription by creating a durable {{TopicSubscriber}} with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.
          {quote}

          This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a {{JMSException}} will be thrown (in the case of {{JMSContext}} a {{JMSRuntimeException}} will be thrown).

          h4.Non-durable subscriptions

          For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

          To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same {{sharedSubscriptionName}}.

          The following new methods on {{Session}} (and its subtypes) are proposed:

          {noformat}
          MessageConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName);
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector)
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
          {noformat}

          Note that if these methods were called simply {{createConsumer}} there would be a clash with the existing method {{createConsumer(Destination destination, String messageSelector)}}. Note that these methods take a {{Topic}}, not a {{Destination}}.

          In the new simplified API, the following new methods on {{JMSContext}} are proposed:

          {noformat}
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
          {noformat}

          Note that a given shared subscription does not exist if there are no consumers using it.
                  
          Nigel Deakin made changes -
          Description This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          h4.Durable subscriptions

          For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

          This affects the following JMS existing JMS 2.1 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}):

          {noformat}
          createDurableSubscriber(Topic topic, String name)
          createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          It also affects the following JMS new JMS 2.0 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}) (added in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]):

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          And in the new JMS 2.0 simplified API, it also affects the following method on {{JMSContext}}:

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

          No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

          {quote}
          By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.
          {quote}

          This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

          However in JMS 2.0, clientId will become optional when creating a durable subscription (see [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39]). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for {{Session.createDurableSubscriber}}):

          {quote}
          A client can change an existing durable subscription by creating a durable {{TopicSubscriber}} with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.
          {quote}

          This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a {{JMSException}} will be thrown (in the case of {{JMSContext}} a {{JMSRuntimeException}} will be thrown).

          h4.Non-durable subscriptions

          For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

          To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same {{sharedSubscriptionName}}.

          The following new methods on {{Session}} (and its subtypes) are proposed:

          {noformat}
          MessageConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName);
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector)
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
          {noformat}

          Note that if these methods were called simply {{createConsumer}} there would be a clash with the existing method {{createConsumer(Destination destination, String messageSelector)}}. Note that these methods take a {{Topic}}, not a {{Destination}}.

          In the new simplified API, the following new methods on {{JMSContext}} are proposed:

          {noformat}
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
          {noformat}

          Note that a given shared subscription does not exist if there are no consumers using it.
                  
          This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple consumers in a Java SE environment. Note that the existing JMS 1.1 API already allows this to be achieved for messages from a queue.

          The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by multiple threads would continue to apply.

          h4.Durable subscriptions

          For durable subscriptions, there would be no need to change the existing API. Applications would simply be allowed to create multiple consumers on the same durable subscription:

          This affects the following JMS existing JMS 2.1 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}):

          {noformat}
          createDurableSubscriber(Topic topic, String name)
          createDurableSubscriber(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          It also affects the following JMS new JMS 2.0 methods on {{Session}} (and its subtypes {{QueueSession}}, {{TopicSession}}, {{XASession}}, {{XAQueueSession}} and {{XATopicSession}}) (added in [JIRA issue 51 | http://java.net/jira/browse/JMS_SPEC-51]):

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          And in the new JMS 2.0 simplified API, it also affects the following method on {{JMSContext}}:

          {noformat}
          createDurableConsumer(Topic topic, String name)
          createDurableConsumer(Topic topic, String name, String messageSelector, boolean noLocal)
          {noformat}

          All these methods currently have a restriction "Only one session at a time can have a TopicSubscriber for a particular durable subscription.". This restriction would be removed.

          No change is proposed to the existing JMS requirement that only one connection may have a given clientID. This is defined in JMS 1.1 Section 4.4.3.2 "Client identifier", which states:

          {quote}
          By definition, the client state identified by a client identifier can be 'in use' by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.
          {quote}

          This means that if a durable subscription is created by a connection with clientId set then it will not be possible to create a second consumer on it using a different connection.

          However in JMS 2.0, clientId will become optional when creating a durable subscription (see [JIRA issue 39|http://java.net/jira/browse/JMS_SPEC-39]). If a durable subscription is created by a connection with clientId unset then other connections may freely create further consumers on the same durable subscription.

          This means that for two message consumers on different connections to share a durable subscription, clientId would need to be left unset.

          In addition, the effect of using a different topic or message selector than was used when the subscription was first created needs to be amended. Currently this states (from the javadoc for {{Session.createDurableSubscriber}}):

          {quote}
          A client can change an existing durable subscription by creating a durable {{TopicSubscriber}} with the same name and a new topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and creating a new one.
          {quote}

          This behaviour will continue, but only if there are no other active consumers on the durable subscription. If there is an active consumer on the durable subscription, and an attempt is made to create an additional consumer with a different topic or message selector, then a {{JMSException}} will be thrown (in the case of {{JMSContext}} a {{JMSRuntimeException}} will be thrown).

          The semantics for the {{unsubscribe}} methods on {{Session}} and {{JMSContext}} would remain unchanged. The javadocs state that "It is erroneous for a client to delete a durable subscription while there is an active {{MessageConsumer}} or {{TopicSubscriber}} for the subscription". This will continue to be the case.

          h4.Non-durable subscriptions

          For non-durable subscriptions, the JMS 1.1 specification specifies that if two non-durable TopicSubscribers are created on the same topic then two independent subscriptions are created: a copy of each message is sent to every consumer on that topic (with an appropriate message selector).

          To allow two consumers to share the same subscription, so that they can share the load of processing messages from that subscription, then new API is required. To allow the consumers to specify that they wish to use the same non-durable subscription, they will need to specify the same {{sharedSubscriptionName}}.

          The following new methods on {{Session}} (and its subtypes) are proposed:

          {noformat}
          MessageConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName);
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector)
          MessageConsumer createSharedConsumer(
             Destination destination, String sharedSubscriptionName, String messageSelector, boolean NoLocal)
          {noformat}

          Note that if these methods were called simply {{createConsumer}} there would be a clash with the existing method {{createConsumer(Destination destination, String messageSelector)}}. Note that these methods take a {{Topic}}, not a {{Destination}}.

          In the new simplified API, the following new methods on {{JMSContext}} are proposed:

          {noformat}
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector)
          JMSConsumer createSharedConsumer(
             Topic topic, String sharedSubscriptionName, String messageSelector, boolean noLocal)
          {noformat}

          Note that a given shared subscription does not exist if there are no consumers using it.
                  
          Nigel Deakin made changes -
          Tags eg pd20-underreview eg
          Nigel Deakin made changes -
          Tags eg
          Nigel Deakin made changes -
          Tags pd20-added
          Nigel Deakin made changes -
          Link This issue blocks MQ-178 [ MQ-178 ]
          Nigel Deakin made changes -
          Assignee Nigel Deakin [ nigeldeakin ]
          amyk made changes -
          Link This issue blocks MQ-168 [ MQ-168 ]
          amyk made changes -
          Link This issue blocks MQ-168 [ MQ-168 ]
          amyk made changes -
          Link This issue blocks MQ-229 [ MQ-229 ]
          Nigel Deakin made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Nigel Deakin made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Nigel Deakin made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Fix Version/s 2.0PD [ 16049 ]
          Resolution Fixed [ 1 ]
          Nigel Deakin made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          amyk made changes -
          Link This issue blocks MQ-175 [ MQ-175 ]
          Nigel Deakin made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Nigel Deakin made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Nigel Deakin made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Fix Version/s 2.0 [ 14692 ]
          Resolution Fixed [ 1 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: