mq
  1. mq
  2. MQ-246

JMSRA support JMS 2.0 shared subscription API

    Details

      Issue Links

        Activity

        Hide
        Ed Bratt added a comment -

        This issue is to track changes to the JMSRA component, related to the JMS 2.0 shared subscription updates. Assigning to Nigel for now. (Split since multiple people are working this issue)

        Show
        Ed Bratt added a comment - This issue is to track changes to the JMSRA component, related to the JMS 2.0 shared subscription updates. Assigning to Nigel for now. (Split since multiple people are working this issue)
        Hide
        Nigel Deakin added a comment -

        This issue covers the implementation of MQ-178 in the JMSRA client (both direct mode and TCP mode). For the avoidance of doubt this issue covers only the JMS API. It does NOT cover message-driven beans.

        The APi required is exactly as defined for MQ-178. However when implementing this feature there is one additional issue to consider. This is how the new JMS 2.0 API for topic subscriptions interacts with JMSRA's existing "shared subscriptions in a cluster" feature.

        The current "shared subscriptions in a cluster" feature (for applications using the JMS API)is defined in
        http://docs.oracle.com/cd/E26576_01/doc.312/e24943/jmsra-properties.htm#gjzpg

        Attempts by multiple connections to use the same client id do not result in an exception, provided that the connections are from different instances in the cluster.

        Two or more subscriptions on the same topic with the same client id and (if the subscription is durable) the same durable subscription name are considered "shared"; that is, they are treated as a single subscription, with each message being sent to only one of the participating subscriptions.

        The sharing of subscriptions relies on client id being set, not only for durable subscriptions (which always require client id) but for non-durable subscriptions (which do not normally require client id). If the subscription is being created by the resource adapter for use by a message-driven bean (MDB), and client id is not set, then the resource adapter will set the client id to the name of the MDB. However if the subscription is being created programmatically using the JMS API, and client id is not set, then an exception will be thrown.

        Now that the JMS 2.0 has decided to keep the existing behaviour of createDurableSubscriber (and createSubscriber), there is no overlap between the two features.

        • createDurableSubscriber and createSubscriber will continue to behave as they do now, with the existing non-spec-complaint "shared subscriptions in a cluster" behaviour (which allows duplicate clientId and requires clientID to be set even for non-durable subscriptions).
        • createSharedConsumer and createSharedDurableConsumer will exhibit the new JMS 2.0 behaviour (and so not support old-style JMSRA shared subscriptions)
        Show
        Nigel Deakin added a comment - This issue covers the implementation of MQ-178 in the JMSRA client (both direct mode and TCP mode). For the avoidance of doubt this issue covers only the JMS API. It does NOT cover message-driven beans. The APi required is exactly as defined for MQ-178 . However when implementing this feature there is one additional issue to consider. This is how the new JMS 2.0 API for topic subscriptions interacts with JMSRA's existing "shared subscriptions in a cluster" feature. The current "shared subscriptions in a cluster" feature (for applications using the JMS API)is defined in http://docs.oracle.com/cd/E26576_01/doc.312/e24943/jmsra-properties.htm#gjzpg Attempts by multiple connections to use the same client id do not result in an exception, provided that the connections are from different instances in the cluster. Two or more subscriptions on the same topic with the same client id and (if the subscription is durable) the same durable subscription name are considered "shared"; that is, they are treated as a single subscription, with each message being sent to only one of the participating subscriptions. The sharing of subscriptions relies on client id being set, not only for durable subscriptions (which always require client id) but for non-durable subscriptions (which do not normally require client id). If the subscription is being created by the resource adapter for use by a message-driven bean (MDB), and client id is not set, then the resource adapter will set the client id to the name of the MDB. However if the subscription is being created programmatically using the JMS API, and client id is not set, then an exception will be thrown. Now that the JMS 2.0 has decided to keep the existing behaviour of createDurableSubscriber (and createSubscriber), there is no overlap between the two features. createDurableSubscriber and createSubscriber will continue to behave as they do now, with the existing non-spec-complaint "shared subscriptions in a cluster" behaviour (which allows duplicate clientId and requires clientID to be set even for non-durable subscriptions). createSharedConsumer and createSharedDurableConsumer will exhibit the new JMS 2.0 behaviour (and so not support old-style JMSRA shared subscriptions)
        Hide
        amyk added a comment -

        updated Summary accordingly

        Show
        amyk added a comment - updated Summary accordingly
        Hide
        amyk added a comment - - edited

        now implemented

        Show
        amyk added a comment - - edited now implemented
        Hide
        saradak added a comment -


        Verified as part of CTS & functional testing.

        Show
        saradak added a comment - Verified as part of CTS & functional testing.

          People

          • Assignee:
            amyk
            Reporter:
            amyk
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: