MDB/Topic/WLS cluster question

Question

          Hi
          I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
          in cluster config where say I have 3 servers with say server#1 hosting the Topic
          [not a distributed destination]. I have an an ear file containing an MDB with
          no pool size limit. After deploying the ear in the cluster - lets say that each
          server on the cluster has 5 instances of the MDB [just an example] and a message
          is published on the Topic.
          Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
          is yes]
          Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
          Q3> Had I had a separate deployment of the same MDB class in the EAR file for
          the same Topic - thats just going to get treated as a completely separate subscriber
          independent of the first MDB though the implementing class is the same - right?
          thanks
          Anamitra
          

Answer 1

          Anamitra wrote:
          > Hi
          > I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
          > in cluster config where say I have 3 servers with say server#1 hosting the Topic
          > [not a distributed destination]. I have an an ear file containing an MDB with
          > no pool size limit. After deploying the ear in the cluster - lets say that each
          > server on the cluster has 5 instances of the MDB [just an example] and a message
          > is published on the Topic.
          >
          > Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
          > is yes]
          Yes.
          > Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
          Yes.
          > Q3> Had I had a separate deployment of the same MDB class in the EAR file for
          > the same Topic - thats just going to get treated as a completely separate subscriber
          > independent of the first MDB though the implementing class is the same - right?
          Yes.
          >
          > thanks
          > Anamitra
          >
          For a little more information, I'm attaching notes on durable
          subscriber MDBs.
          A JMS durable subscription is uniquely identified within a cluster by a combination of "connection-id" and "subscription-id". Only one active connection may use a particular "connection-id" within a WebLogic cluster.
          In WebLogic 8.1 and previous, a durable topic subscriber MDB uses its name to generate its client-id. Since JMS enforces uniqueness on this client-id, this means that if a durable subscriber MDB is deployed to multiple servers only one server will be able to connect. Some applications want a different behavior where
          each MDB pool on each server gets its own durable subscription.
          The MDB connection id, which is unique within a cluster, comes from:
          1) The "ClientId" attribute configured on the WebLogic connection factory.
          This defaults to null. Note that if the ClientId is set on a connection
          factory, only one connection created by the factory
          may be active at a time.
          2) If (1) is not set, then, as with the subscriber-id,
          the connection-id is derived from jms-client-id descriptor attribute:
          <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          3) If (1) and (2) are not set, then, as with the subscriber-id,
          the connection-id is derived from the ejb name.
          The MDB durable subscription id, which must be unique on its topic, comes from:
          1) <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          2) if (1) is not set then the client-id
          comes from the ejb name.
          The above prevents a durable topic subscriber MDB from running on multiple servers. When an instance of the MDB starts on another server, it deploys successfully, but a conflict is detected and the MDB fails to fully connect to JMS. The work-around is the following:
          A) Create a custom connection-factory for each server:
          1) configure "JNDIName" to the same value across all servers
          ("myMDBCF" in this example)
          2) configure "ClientId" to a unique value per server
          3) enable "UserTransactionsEnabled"
          4) enable "XAConnectionFactoryEnabled"
          5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
          6) target the CF at a single WebLogic server
          (Number 5 is required for non-transactional topic MDBs)
          B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
          factory to the JNDI name of the custom connection factories configured in
          (A). Optionally, also specify the subscriber-id via the jms-client-id
          attribute.
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>exampleBean</ejb-name>
          <message-driven-descriptor>
          <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
          <jms-client-id>myClientID</jms-client-id>
          </message-driven-descriptor>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          C) Target the application at the same servers that have the custom connection
          factories targeted at them.
          Notes/Limitations:
          1) If the MDB is moved from one server to another, the MDB's corresponding
          connection-factory must be moved with it.
          2) This work-around will not work if the destination is not in the same
          cluster as the MDB. (The MDB can not use the local connection factory, which
          contains the connection-id, as connection factories do not work unless they
          are in the same cluster as the destination.)
          3) This work-around will not work for non-WebLogic JMS topics.
          4) A copy of each message is sent to each to each server's MDB pool.