jms-spec
  1. jms-spec
  2. JMS_SPEC-73

Define how messages from a topic are delivered to clustered application server instances

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      This issue was raised on the JMS forum:
      https://forums.oracle.com/forums/thread.jspa?threadID=2124417
      and is being logged here on behalf of that contributor

      How many times are topic messages delivered ?

      This may seem to be a trivial question, but when clustering is involved, it's not.

      JEE has strong support for clustering, but many JEE specifications do not define what is actually supported, and leaves room for application server specific features. This is the case for JMS in the various specifications involved (JMS, JEE, EJB, JCA).

      The question is how many times are messages delivered and treated (e.g. once per cluster or once per application server)?

      Note that to simplify the problem I will not address selectors, delivery modes or acknowledgement considerations. I will also only address business application clustering, not JMS implementation clustering.

      When Queues are used the situation is quite clear, the message is delivered once whether you use clustering or not. But when Topics are used, there is no simple answer.

      When a message is sent to a Topic, each currently active non-durable subscriber should receive the message once. If the receiving application is clustered, the message should be received one time per application server instance in the cluster. That's what we get with JBoss 4.2.3.

      This is actually not always the case. One example with WebSphere 6.1:

      • A business application is deployed to a cluster of two application servers
      • The JMS message engine is also deployed to a cluster of two application servers
      • The application uses a MDB with a non-durable subscription to a Topic
      • A message is sent to that Topic
        If the two clusters are different, then the message is received by one MDB on each application instance, so the message is treated twice. But if the two clusters are actually the same, then the message is only received by one MDB instance on the application server where the message engine instance runs, so the message is treated once instead of twice. Painful.

      For reliability considerations, enterprise applications often use durable subscriptions to Topics. This makes the situation even more complicated.

      Durable subscriptions are identified by a subscription name. This defines the number of deliveries, meaning that the message should be delivered once per distinct subscription name.

      JMS offers three ways to receive messages: Message Driven Beans (MDB), synchronous receptions using MessageConsumer:receive and explicit message listeners using MessageConsummer:setMessageListener. We won't address message listeners as they are forbidden on the server side by the JEE specifications.

      When doing synchronous receptions or message listeners, the durable subscription name is managed by the developper using Session:createDurableSubscriber. This way it is possible (it is actually required by the JMS specification) to give a different name per application instance in the cluster to choose the number of times the messages are received.

      With MDB we cannot officially manage the subscription name, so there is not portable control of the number of messages delivery. Note that we cannot manage the client ID either. In more details, both client ID and subscription name are valid parameters as per the JCA specification, but they are not according to the EJB specification.

      We need precise, portable and cluster compliant semantics about the number of time JMS messages get delivered.

        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 -
          Description This issue was raised on the JMS forum:
          https://forums.oracle.com/forums/thread.jspa?threadID=2124417
          and is being logged here on behalf of that contributor

          How many times are topic messages delivered ?

          This may seem to be a trivial question, but when clustering is involved, it's not.

          JEE has strong support for clustering, but many JEE specifications do not define what is actually supported, and leaves room for application server specific features. This is the case for JMS in the various specifications involved (JMS, JEE, EJB, JCA).

          The question is how many times are messages delivered and treated (e.g. once per cluster or once per application server)?

          Note that to simplify the problem I will not address selectors, delivery modes or acknowledgement considerations. I will also only address business application clustering, not JMS implementation clustering.

          When Queues are used the situation is quite clear, the message is delivered once whether you use clustering or not. But when Topics are used, there is no simple answer.

          When a message is sent to a Topic, each currently active non-durable subscriber should receive the message once. If the receiving application is clustered, the message should be received one time per application server instance in the cluster. That's what we get with JBoss 4.2.3.

          This is actually not always the case. One example with WebSphere 6.1:
          - A business application is deployed to a cluster of two application servers
          - The JMS message engine is also deployed to a cluster of two application servers
          - The application uses a MDB with a non-durable subscription to a Topic
          - A message is sent to that Topic
          If the two clusters are different, then the message is received by one MDB on each application instance, so the message is treated twice. But if the two clusters are actually the same, then the message is only received by one MDB instance on the application server where the message engine instance runs, so the message is treated once instead of twice. Painful.

          For reliability considerations, enterprise applications often use durable subscriptions to Topics. This makes the situation even more complicated.

          Durable subscriptions are identified by a subscription name. This defines the number of deliveries, meaning that the message should be delivered once per distinct subscription name.

          JMS offers three ways to receive messages: Message Driven Beans (MDB), synchronous receptions using MessageConsumer:receive and explicit message listeners using MessageConsummer:setMessageListener. We won't address message listeners as they are forbidden on the server side by the JEE specifications.

          When doing synchronous receptions or message listeners, the durable subscription name is managed by the developper using Session:createDurableSubscriber. This way it is possible (it is actually required by the JMS specification) to give a different name per application instance in the cluster to choose the number of times the messages are received.

          With MDB we cannot officially manage the subscription name, so there is not portable control of the number of messages delivery. Note that we cannot manage the client ID either. In more details, both client ID and subscription name are valid parameters as per the JCA specification, but they are not according to the EJB specification.

          We need precise, portable and cluster compliant semantics about the number of time JMS messages get delivered.

          This issue was raised on the JMS forum:
          https://forums.oracle.com/forums/thread.jspa?threadID=2124417
          and is being logged here on behalf of that contributor

          {quote}
          How many times are topic messages delivered ?

          This may seem to be a trivial question, but when clustering is involved, it's not.

          JEE has strong support for clustering, but many JEE specifications do not define what is actually supported, and leaves room for application server specific features. This is the case for JMS in the various specifications involved (JMS, JEE, EJB, JCA).

          The question is how many times are messages delivered and treated (e.g. once per cluster or once per application server)?

          Note that to simplify the problem I will not address selectors, delivery modes or acknowledgement considerations. I will also only address business application clustering, not JMS implementation clustering.

          When Queues are used the situation is quite clear, the message is delivered once whether you use clustering or not. But when Topics are used, there is no simple answer.

          When a message is sent to a Topic, each currently active non-durable subscriber should receive the message once. If the receiving application is clustered, the message should be received one time per application server instance in the cluster. That's what we get with JBoss 4.2.3.

          This is actually not always the case. One example with WebSphere 6.1:
          - A business application is deployed to a cluster of two application servers
          - The JMS message engine is also deployed to a cluster of two application servers
          - The application uses a MDB with a non-durable subscription to a Topic
          - A message is sent to that Topic
          If the two clusters are different, then the message is received by one MDB on each application instance, so the message is treated twice. But if the two clusters are actually the same, then the message is only received by one MDB instance on the application server where the message engine instance runs, so the message is treated once instead of twice. Painful.

          For reliability considerations, enterprise applications often use durable subscriptions to Topics. This makes the situation even more complicated.

          Durable subscriptions are identified by a subscription name. This defines the number of deliveries, meaning that the message should be delivered once per distinct subscription name.

          JMS offers three ways to receive messages: Message Driven Beans (MDB), synchronous receptions using MessageConsumer:receive and explicit message listeners using MessageConsummer:setMessageListener. We won't address message listeners as they are forbidden on the server side by the JEE specifications.

          When doing synchronous receptions or message listeners, the durable subscription name is managed by the developper using Session:createDurableSubscriber. This way it is possible (it is actually required by the JMS specification) to give a different name per application instance in the cluster to choose the number of times the messages are received.

          With MDB we cannot officially manage the subscription name, so there is not portable control of the number of messages delivery. Note that we cannot manage the client ID either. In more details, both client ID and subscription name are valid parameters as per the JCA specification, but they are not according to the EJB specification.

          We need precise, portable and cluster compliant semantics about the number of time JMS messages get delivered.
          {quote}
          Nigel Deakin made changes -
          Tags pd20-forreview
          Nigel Deakin made changes -
          Tags pd20-forreview
          Nigel Deakin made changes -
          Tags pd20-forreview-minor
          Nigel Deakin made changes -
          Tags pd20-forreview-minor
          Nigel Deakin made changes -
          Tags pd20-forreview-major
          Nigel Deakin made changes -
          Tags pd20-forreview-major
          Nigel Deakin made changes -
          Tags pd20-forreview-major
          Nigel Deakin made changes -
          Tags pd20-forreview-major
          Nigel Deakin made changes -
          Tags pd20-added
          Nigel Deakin made changes -
          Fix Version/s 2.0PD [ 16049 ]
          Fix Version/s 2.0 [ 14692 ]
          Nigel Deakin made changes -
          Assignee Nigel Deakin [ nigeldeakin ]
          Nigel Deakin made changes -
          Link This issue blocks JMS_SPEC-103 [ JMS_SPEC-103 ]
          Nigel Deakin made changes -
          Link This issue blocks MQ-193 [ MQ-193 ]
          Nigel Deakin made changes -
          Link This issue blocks MQ-193 [ MQ-193 ]
          Nigel Deakin made changes -
          Link This issue blocks MQ-251 [ MQ-251 ]
          Nigel Deakin made changes -
          Comment [ The expected behaviour is now described in the EJB 3.2 spec, which contains two new sections which define how JMS MDBs should behave:

          {quote}
          *5.4.16.7 Subscription Name*

          If the message-driven bean is intended to be used with a Topic, and the bean provider has indicated that a durable subscription should be used by specifying the {{subscriptionDurability}} property to {{Durable}}, then the bean provider or deployer may specify the name of the durable subscription.

          The name of the durable subscription may be specified by using the {{activationConfig}} element of the {{MessageDriven}} annotation or by using the {{activation-config-property}} deployment descriptor element. The property name used to specify the name of the durable subscription is {{subscriptionName}}.

          If a durable subscription is specified but subscriptionName is not specified then the container will set the name of the durable subscription to be a name which is unique to the deployed MDB (see 5.7.3). If the message-driven bean is deployed into a clustered application server then the shareSubscriptions property will be used to determine whether the durable subscription name generated by the container will be the same or different for each instance in the cluster.

          *5.4.16.8 Durable Subscription Name in Clustered Deployment*

          If message-driven bean is intended to be used with a Topic and the bean provider or deployer has specified that a durable subscription be used but has not specified a durable subscription name then the bean provider or deployer may specify whether the durable subscription name generated by the container will be the same or different for each instance in the cluster.

          If message-driven bean is intended to be used with a topic and the bean provider or deployer has specified that a non-durable subscription be used then the bean provider or deployer may specify whether the same non-durable subscription should be used for each instance in the cluster.

          This may be specified by using the {{activationConfig}} element of the {{MessageDriven}} annotation or by using the {{activation-config-property}} deployment descriptor element. The property name used is {{shareSubscriptions}}.

          This property is only used if the message-driven bean is deployed into a clustered application server. The property may have the string values {{true}} or {{false}}.

          A value of {{true}} means that the same durable subscription name or non-durable subscription will be used for each instance in the cluster.

          A value of {{false}} means that a different durable subscription name or non-durable subscription will be used for each instance in the cluster.

          By default a value of true is assumed.
          {quote} ]
          Nigel Deakin made changes -
          Tags pd20-added
          Nigel Deakin made changes -
          Tags jms21-forreview-major
          Nigel Deakin made changes -
          Link This issue blocks MQ-251 [ MQ-251 ]
          Nigel Deakin made changes -
          Fix Version/s 2.0 [ 14692 ]
          Fix Version/s 2.0PD [ 16049 ]

            People

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

              Dates

              • Created:
                Updated: