MDB as a topic subscriber

Hi,
I am a little confused as to how would i bind a MDB on a topic.
Usually any MDB implements Message Listener interface and hence we write the implementation for OnMessage method.
I have succesfully writen to make MDB listen to a queue, but i am confused about the same for topic. Usually for the topic, the client who is listening to the topic needs to implement startListener() ... now the startListener() has to be called/invoked by somebody.
In my case i want an MDB to start listening to a topic on another Server, how can i do this ?
I did quite alot of search on net but didnt come up with what i needed ?
Code snippets are very much appreciated, even a small tutorial ...
TIA
Meka Toka

Let me be more clear,
I implemented a Topic, where an application client is listening to a Topic, and the message is being published by an ejb on a server. In this scenario i wrote a message listener class on the client side, i had a start listener method, in which i would do the lookup, create topic connection and start the listener. And the start listener method had to be called/invoked, then only the client would listen to the topic.
If i wanted a MDB to listen to topic, do i need the startlistener method ??
if Yes, who invokes the method ?
if NO, does it mean the MDB is directly bound to the topic ?
Now MDB has an OnMessage() method, in which we write what to do after u get the message ? But my question is how to bind the topic in the first place ?
I know that we can do the settings in the ejb-jar.xml where in you would give the message destination and all. But what about the lookup ? It needs to know the ip address of the topic destination from where it needs to retirieve.
Can some body guide me if i am missing something ?
TIA
Meka Toka

Similar Messages

  • Session EJB as a Topic subscriber

    Hi ,
    is it possible to create a topic subscriber inside a session ejb( both stateless and stateful ) with an asynchronous message listener ?
    Regards,
    Sajith

    A<WSI-17> WLS6.1 does not support Stateful Session beans as web services. Maintaining
    client state is a complex problem for web services that does not have a proper solution
    in the J2EE framework (stateful session and HTTP sessions are inappropriate). WLS
    7.0 does provide a web service capability for storing client data using an entity
    bean.
    "Elie Dagher" <[email protected]> wrote:
    >
    Q:WSI17-Does weblogic support Stateful session Ejb as a Web service?

  • MDB on distributed topic issue (server restart)

    Setup:
              - On WebLogic 8.1 SP3, One cluster with 2 managed servers, S1 and S2.
              - JMS servers are configured for both S1 and S2.
              - ConnectionFactory(load balancing=true, server affinity=false, XA Transaction=true) is deployed to the cluster
              - Distributed topic, DT1, deployed to the cluster with physical memeber on each JMS server, T1 on S1, T2 on S2
              - MDB for DT1 is deployed in both S1 and S2
              - Sending message to DT1 thru a session bean with container managed transaction.
              Test:
              1. Start both server, and send 10 messages to DT1, evenrything is fine, both servers received 10 messsage each
              2. Shutdown S2
              3. Send another 10 messages to DT1, S1 received 10 messages thru MDB deployed on it, and noticed that there are 10 messages pending for T1 (by using console destination monitoring function)
              4. Restart S2
              5. When S2 is fully restarted, noticed that the 10 pending messages are gone for T1, but S1 printout 10 Alert: Tx heuristic result
              6. then, if send another 10 messages thru session bean in S1, both servers receives 10 messages each; if send another 10 messages thru session bean in S2, only S2 will receive them all, S1 receives nothing and noticed that 10 messages pending for T2
              Someone posted a similar issue before, but no clear answer on exactly what happened and how to fix it.
              Thanks,
              JD

    The errors are:
              <17-Feb-2005 4:40:45 o'clock PM EST> <Error> <JTA> <BEA-110412> <Xid=BEA1-054635FA5A4B74B8B574(14775730),Status=Committed,HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=300,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=server2),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@e8b13,re-Registered = false),SCInfo[NakinaDomain+server2]=(state=committed)) completed heuristically: (weblogic.jdbc.wrapper.JTSXAResourceImpl, HeuristicHazard, (javax.transaction.xa.XAException: No connection associated with xid = BEA1-054635FA5A4B74B8B574-7765626C6F6769632E6A6462632
              E777261707065722E4A545358415265736F75726365496D706C)) >

  • Topic subscriber in JMS cluster

              I have clustered 2 JMS servers, A and B. The subscriber is listening to the topic
              . The subscriber used the cluster ip address in the intial context to connect to
              the server t3://A,B:7010 and listen to the topic . FYI The connection factory is
              deployed to the cluster.
              The subscriber receives the message sent by the publisher.
              But when say server A fails , the Publisher still can publish messages to server
              B (failover works) , but the subscriber stops receiving the messages.
              I thought in clustered environment the subscriber would still receive messages if
              it connects to the topic using the connection factory deployed on the cluster.
              Can somebody throw an insight!!
              Thanks
              Ashok
              

    I assume you're on 6.0?
              Which server did you target your topic? If that server fails, then no, you will not be able to
              subscribe to anything...
              Gene
              "ashok shamnani" <[email protected]> wrote in message news:3a880141$[email protected]..
              >
              > I have clustered 2 JMS servers, A and B. The subscriber is listening to the topic
              > The subscriber used the cluster ip address in the intial context to connect to
              > the server t3://A,B:7010 and listen to the topic . FYI The connection factory is
              > deployed to the cluster.
              >
              > The subscriber receives the message sent by the publisher.
              > But when say server A fails , the Publisher still can publish messages to server
              > B (failover works) , but the subscriber stops receiving the messages.
              >
              > I thought in clustered environment the subscriber would still receive messages if
              > it connects to the topic using the connection factory deployed on the cluster.
              >
              > Can somebody throw an insight!!
              >
              > Thanks
              > Ashok
              

  • Topic subscriber not receive messages

    Hi,
    I have a simple jms topic application.
    I use the default topic demoTopic and the defaul connection factory.
    But the subscriber don't works, the onMessage method of the listener is never called...
    this is the code for the publisher:
    ctx = new InitialContext();
    tcf = (TopicConnectionFactory) ctx.lookup("jms/TopicConnectionFactory");
    topicConnection = tcf.createTopicConnection();
    topicConnection.setClientID("111111");
    topicSession = topicConnection.createTopicSession(true,Session.CLIENT_ACKNOWLEDGE);
    topic = (Topic) ctx.lookup("jms/demoTopic");//topicSession.createTopic(conf.topic);
    publisher = topicSession.createPublisher(topic);
    this is the code for the subscriber:
    ctx = new InitialContext();
    tcf = (TopicConnectionFactory) ctx.lookup("jms/TopicConnectionFactory");
    topicConnection = tcf.createTopicConnection();
    topicConnection.setClientID("111111");
    this.setTopicConnection(topicConnection);
    topicSession = topicConnection.createTopicSession(true,Session.CLIENT_ACKNOWLEDGE);
    topic = (Topic) ctx.lookup("jms/demoTopic");//topicSession.createTopic(conf.topic);
    topicListener = new HeartbeatTopicListener(topicSession, heartbeat);
    topicSubscriber = topicSession.createDurableSubscriber(topic,conf.durableSubscriberName);
    topicSubscriber.setMessageListener(topicListener);
    The publisher works fine...in the log file the calling of the send method appear correct, but the subscriber not responds...
    Any suggestion?
    Thanks

    Where is the producer and consumer code running? Server container (OC4J), Client container (application client), plain jms client.
    Besides traditional "check the log for exception" tips.
    0) register an ExceptionListener on the connection. If you are not using the connection other than for the MessageListener, you will not learn about Exceptions without setting an ExceptionListener.
    1) make sure that there are no race conditions:
    a) the listener infrastructure is set up before messages you want to receive are sent
    b) a JMS Session object is used only by one thread. E.g., when a MessageListener is used, JMS spec prohibits using the same session from other threads (using it MessageProducers/Consumers etc). Only close() methods can be called from other threads.
    2) I don't expect this to be a problem here since OC4J JMS does not enforce the client id uniqueness, however, the JMS spec prohibits two concurrent connections with the same client id as in your example. It were a problem if you used NoLocal when creating the subscriber.
    3) Check that you are not using a too restrictive/buggy selector.
    Gera

  • EJB 3.0 MDB configuration for Topic w/ Group only read access

    We currently have a Topic on a weblogic server (10.3) in which the security access has been turned on to only allow certain users to read from that topic.
    The issue we are having is finding the necessary documentation to how to set which user that the MDBs will use when running on the app server.
    I've tried both of these properties, but haven't had any luck yet:
    <run-as-principal-name></run-as-principal-name>
    <create-as-principal-name></create-as-principal-name>
    Any ideas/documentation on how to configure it so the MDB can also listen to the topic. The MDB won't always be on the same server as the JMS as well.
    Thanks

    This page helps -- not sure if there are any other thoughts/comments/newer ways of doing it.
    http://stackoverflow.com/questions/4887427/weblogic-message-driven-bean-reading-from-a-secured-queue-runas-does-not-work
    Thanks.

  • MDB Publish to Topic/Queue

    Does anyone know if its "bad practice" to have an MDB publish to a Topic or Queue.
    Say I have FooMDB listening on Topic1 and I want FooMDB to publish to Topic2 if "somethign happens" or just finish the onMessage if "something else happens". That way when Topic2 recieves the message Foo2MDB receives the message and does its thing.
    I have this working but I can't find anything that says I shouldn't do this .... Any thoughts??
    Thanks

    Hi,
    did you try a manual acknowledge? Something like
    public void onMessage(Message msg) {
       try {
          msg.acknowledge();
       } catch (JMSException e) {
          // handle it
       }When you create a new QueueSession, you have to set it to
    Session.CLIENT_ACKNOWLEDGEIn your case, JMS waits until the complete transaction (even with the
    decision what to do, the forward and so on) are done successfully. With
    CLIENT_ACKNOWLEDGE you tell JMS you got the message and will
    take care of the rest.
    -Danny

  • MDBs and local topics

    Hi all,
              I have a WLS JMS queue being fed by a bridge that pulls messages from MQ. That queue sorts the messages into 4 outgoing topics. One of the consumers of one of those topics is a local MDB. External consumers create durable subscriptions so they don't miss messages. Should my internal consumer (part of the same EJB jar that sorts the messages in the first place) also create a durable subscription? Is there any danger of missing messages?
              thanks

    Hi,
              The internal consumer may miss messages. If the server crashes before your onMessage() completes processing any message backlog, the messages will not be redelivered.
              If the internal consumer onMessage is sufficiently fast, and if I understand your app well enough, it seems that there may be a way to avoid the need for a local consumer MDB in the first place: the "sort" code itself could directly invoke a local stateless session bean that does the same thing as the MDB...
              Tom

  • Invalid handle if topic subscriber run from javaw

    Hi.
    I'm new to JMS but have just written a fairly straightforward pub/sub application which runs absolutely fine when the subscriber client is started using 'java'.
    You'll notice that, when you go through the process of setting up context, factory, and so on, the JMS implementation built into J2EE comes up with a 'welcome' message on standard output:
    Java(TM) MessageService 1.0.2 Reference Implementation (build b14)
    However, I'd like to run this subscriber client without a Java console. When I try to do this (using javaw), I get an i/o exception as the subscriber starts up with an 'invalid handle' as the exception message. I presume my app is getting upset because the JMS server doesn't have a console for its welcome message.
    Maybe the workaround is blindingly obvious, but I can't see it at the moment. Can anyone tell me how to re-direct the welcome message or get rid of it completely ?

    Problem solved - please ignore posting.

  • Deploy MDBs in Different WL Instances Subscribed to Same Topic

              Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different Weblogic
              server. All need to subscribe to the same Topic. How is this done? Specifically,
              how is the Topic configured and how are the MBDs deployed?
              Thanks,
              Jim Goodwin
              

    For your reading enjoyment, I'm posting some of my
              internal notes on durable subscriber MDB's. This consolidates
              newsgroup information in one place.
              Jim Goodwin wrote:
              > "Jim Goodwin" <[email protected]> wrote:
              >
              >>Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different
              >>Weblogic
              >>server. All need to subscribe to the same Topic. How is this done? Specifically,
              >>how is the Topic configured and how are the MBDs deployed?
              >>
              >>Thanks,
              >>
              >>Jim Goodwin
              >
              >
              > Bah! Nevermind. I found the information I was looking for in other threads.
              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 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 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.
              The connection id 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.
              Work-around:
              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.
              

  • How to configure MDB as Durable Subscriber

              I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
              I tried using the Edit EJB Descriptor link in the console. I then drilled down
              to Message Driven Destination. For Subscription Durability, I selected Durable.
              I clicked Apply. I also went back to the jar and pressed the Persist button to
              "Persist changes made to the Descriptor(s)".
              I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
              the server. Still no.
              What am I missing? The only info I can find in the documentation about setting
              up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
              Using WL v6 SP5, not clustered.
              Any help would be appreciated.
              Jim
              

    Hi James,
              I'm unfamiliar with the console ejb xml editor. I suggest
              posting to the ejb newsgbroup, which is more familiar
              with these things. Meanwhile, the attached notes
              and the following example may help if your willing
              to hand-edit the xml.
              Tom, BEA
              <ejb-jar>
              <enterprise-beans>
              <message-driven>
              <ejb-name>exampleMessageDrivenA</ejb-name>
              <ejb-class>MessageBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              <!--
              <destination-type>javax.jms.Topic</destination-type>
              <subscription-durability>Durable</subscription-durability>
              -->
              </message-driven-destination>
              </message-driven>
              </enterprise-beans>
              <assembly-descriptor>
              <container-transaction>
              <method>
              <ejb-name>exampleMessageDrivenA</ejb-name>
              <method-name>onMessage()</method-name>
              </method>
              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              </assembly-descriptor>
              </ejb-jar>
              <!-- Sample MessageDriven bean Weblogic deployment descriptor -->
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleMessageDrivenA</ejb-name>
              <message-driven-descriptor>
              <pool>
              <max-beans-in-free-pool>5</max-beans-in-free-pool>
              <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
              </pool>
              <!--
              <destination-jndi-name>quotestopic</destination-jndi-name>
              -->
              <destination-jndi-name>MDBQ</destination-jndi-name>
              <!--
              <provider-url>t3://localhost:10001</provider-url>
              <connection-factory-jndi-name>cf3</connection-factory-jndi-name>
              <jms-client-id>cid444</jms-client-id>
              -->
              </message-driven-descriptor>
              <jndi-name>someid</jndi-name>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              James Goodwin wrote:
              > I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
              > I tried using the Edit EJB Descriptor link in the console. I then drilled down
              > to Message Driven Destination. For Subscription Durability, I selected Durable.
              > I clicked Apply. I also went back to the jar and pressed the Persist button to
              > "Persist changes made to the Descriptor(s)".
              >
              > I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
              > the server. Still no.
              >
              > What am I missing? The only info I can find in the documentation about setting
              > up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
              >
              > Using WL v6 SP5, not clustered.
              >
              > Any help would be appreciated.
              >
              > Jim
              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 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 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.
              The connection id 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.
              Work-around:
              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.
              

  • MDB rollback to Queues/Topics

    Can somebody explain the MDB rollback behaviour in Queues and Topics.
    My specific questions are:
    1) When a MDB, listening to a Queue, performs a rollback, does the message go back to the head of the queue (assumption is that the message should go back to the head of the queue)? Is this somewhere in the spec? Seems like different providers have different interpretations, all the JMS providers do not gurantee this behaviour.
    2) If we replace the queue with Topic, where does the message go on a rollback?
    3) Where does the message go when there are multiple subscribers to the Topic? Can the other subscribers that did consume the message successfully get the message again, if a subscriber performs a rollback?
    The JMS specification does not cover these situation very well, so we are left to the mercy of the JMS providers.
    4) Can somebody share the experience in this context, if we are trying to build a 'JMS agnostic' solution, how should we handle this rollback?
    Thanks

    1. Its dependent on the JMS provider. In ActiveMQ 4.x it is replayed to the consumer a number of times before being placed on the head of the queue - so ordering is maintained if the message is successfully processed by the same consumer.
    However ordering is often broken if the message is put back on the head of the queue if you have multiple consumers, since they compete for messages. Though if you have multiple consumers anyway, you often loose total ordering unless you use a technique like Exclusive Queues or Message Groups.
    2. Typically it'll be replayed to the same consumer again. Most JMS providers provide a way to customize the redelivery policy; how many times will it be redelivered before sending to a dead letter queue, what is the replay exponential back off time etc.
    3. Yes. Each topic subscriber gets their own copy of the message. It doesn't matter if one consumer does or does not process the message; other consumers are unaffected.
    4. I'd just retry the operation and rely on the MDB/JMS providers dead letter queue and you should be fine.
    BTW if ever you need a tool to browse the dead letter queues and maybe move messages from the dead letter queue back to the originating queue, you could try Hermes
    http://www.hermesjms.com/
    James
    http://logicblaze.com/

  • MDB/Topic/WLS cluster 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
              

              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.
              

  • Messages for Durable Subscriber are not persisted with Distributed Topic

    Setup:
              - Weblogic 8.1 SP 6 cluster with two nodes on single Sun Solaris 5.8 host
              - Distributed topic destination, separate JMS server with separate filestore for each node
              - Standalone durable JMS client connecting to distributed topic destination using specific JNDI name.
              - Messages are persistent (msg.setJMSDeliveryMode(DeliveryMode.PERSISTENT). Delivery mode override for topic destinations is set to "Persistent"
              Test:
              1) Both nodes up, starting durable topic subscriber -> durable subscriber is visible in Weblogic console -> sending X messages -> X messages are received :-)
              2) Both nodes up, killing durable topic subscriber -> durable subscriber is still visible in Weblogic console -> sending X messages -> Messages Current Count for durable subscribers is set to X -> starting JMS client again
              2a) subscribing to same node as before -> console says durable subscriber is active again -> X messages are received :-)
              2b) subscribing to other node -> durable subscriber is automatically migrated by Weblogic to this node, console says that subscriber is active, but Messages Current Count is 0 (zero) -> 0 (zero) messages are received :_|
              Where are my X messages gone?
              Should I open a call or did I misunderstand the basics?
              Thanks, Peter

    According to Bea Customer Support this is the normal behavior. If you kill a durable topic subscriber and reconnect it with the same id to another node, the old subscription is deleted and all messages still waiting to be delivered are gone.
              Lesson learned: If you need failover for the server AND client use JMS queues.
              Peter

  • Messages in JMS Topic Error destination

    Hi,
    I have a JMS Topic with an error destination queue configured. Now, In our scenario , there are two subscribers of topic for the same message. Suppose for a message published to topic, subscriber1 is able to processes message successfully but subscriber2 throws errors when processing the same message.
    1. Once the redelivery limit is reached and subscriber2 continues to throw exception, Will the message get en queued to Error Destination (in spite of the fact that subscriber 1 has processed the same message successfully) ?
    2. For a consumer (e.g MDB) listening to Error destination and consuming error messages, Is it possible to determine which topic subscriber was unable to process the message ?
    Please let me know
    Regards,
    Arif

    Here it depends on the state of the message, if the message is visible then the message would be available for consumption, else it is not. In case the subscriber 2 failed to consume the message and the message is still visible then a retry would be made, else the message would not be retried.
    In case the message is visible then the message would be move to the error queue based on the configured redelivery attempts.
    Additionally, an MDB can find the destination using the getJMSDestination() call. But as per my understanding we will only be able to get the name of the last destination which in this case would be error queue:
    http://docs.oracle.com/javaee/1.4/api/javax/jms/Message.html#getJMSDestination%28%29

Maybe you are looking for