Jms queue multiple consumers

Hi,
I am new to the JMS queue concept. I have two BPEL processes each having JMS adapter for consuming the data from the same queue. How do i differentiate which consumer consumes which data that is put into the queue. Is there any field in the queue that decides which consumer has to consume the message.
Just to add to above query, if the message goes to all the consumers, is there any way that i put some logic there to let only the eligible consumer actually process that message.
It would be helpful if i get any documentation on this.
Thanks in advance for the Help!
Edited by: Marius J on Jun 2, 2009 7:38 AM

Thanks Sahil and JDT. Thanks for the response.
Sahil,
I was able to proceed the way u specified. I am using AQ. How do i send the corrid while enqueuing the data in the queue. I am using the following command to enqueue the data.
CONNECT aq_user/aq_user@tsh9i
DECLARE
l_enqueue_options     DBMS_AQ.enqueue_options_t;
l_message_properties  DBMS_AQ.message_properties_t;
l_message_handle      RAW(16);
l_event_msg           AQ_ADMIN.event_msg_type;
BEGIN
l_event_msg := AQ_ADMIN.event_msg_type('REPORTER', 1, 2);
DBMS_AQ.enqueue(queue_name          => 'aq_admin.event_queue',
enqueue_options     => l_enqueue_options,
message_properties  => l_message_properties,
payload             => l_event_msg,
msgid               => l_message_handle);
COMMIT;
END
But, as per your inputs, we need to send corrid in order to meet my requirement. Can u please guide me regarding this.
Thanks again
Regards,
MJ
Edited by: Marius J on Jun 4, 2009 7:39 AM

Similar Messages

  • JMS Queue - 2 Consumers from single Queue

    Hi,
    I have a scenario like, there is a single which has records. Of which some records need to be send to 1 application and some records need to be sent to anothere appln.
    So, there are two consumers for this Queue.
    How to implement this in SOA?
    Is selecting the data based on a flag possible?
    Thanks,
    Priya

    You can use Message Selectors for this. Please refer the below link
    SOA 11g- Message Selector Property in JMS Adapter - Oracle Fusion Middleware Blog

  • Could multiple consumers attach to a JMS queue simultaneously?

    Could a JMS message queue have multiple consumers simultaneously? If can, how to implement that? My experiences showed that at any time there is only one consumer allowed for a JMS message queue. If a subsequent consumer tried to attach to the same queue, the following exception would be thrown out:
    =====================================================
    javax.jms.ResourceAllocationException: [C4073]: A JMS destination limit was reached. Too many Subscribers/Receivers for Queue : PhysicalQueue user=guest, broker=CTPLIT015PC:7676(1462)======================================================
    On the contrary, definitely multiple consumers can be attached to the same Topic.

    Well I need tor receive a message only once and this is why I would still have to use a queue. I have heard selector are slow so I do not want to use them.
    Now the problem is since I am using onMessage event; the message push is like 150 message/second. While the message dequeue process always stuck up at 14 message/second.
    I really need to increase the speed some good number may be 50 messages/second. I need to know whether I need to setup a threadmanager (with threadpool) in onMessage event, or I need to create multiple queue session.
    If I create multiple queue session what would be the behavior of queue?
    My main concern is to get this number up.
    regards
    shantanu

  • Multiple consumers of the same Queue

    In the past my use of JMS queues has been limited to a single message producer and a single consumer. I am now looking at having multiple copies of the same consumer running for load balancing and failover purposes, and this leads me to what I think is a basic question. BTW, we're running OpenMQ 4.4u1.
    I have messages being produced and saved in a single queue.
    I then have a consumer program whose logic is something like this:
    1. Create session with no transaction and CLIENT_ACKNOWLEDGE.
    2. Receive message from queue.
    3. Do some processing with message. Repeat processing attempts multiple times, if needed, until successful.
    4. Once processing is successful, acknowledge message.
    Assume that I am running multiple copies of the consumer in separate JVMs (or on separate servers, for that matter).
    Here are my related questions.
    1. If step 3 takes a long time (e.g., several minutes) can I be sure that only one instance of the consumer will receive the message?
    2. If a consumer is in step 3 and a catastrophic failure occurs (e.g., the JVM or server it is running on crashes) the message will never be acknowledged, but the session will not be shut down in an orderly fashion, either. Will the message that was received but never acknowledged eventually be delivered to another copy of the consumer?
    3. If step three takes a very long time (hours or days, rather than minutes), will the broker misinterpret this as a failure of the consumer and deliver the same message to another one of the consumers?
    Thank you for reading and/or responding to this question.
    Bill

    1. If step 3 takes a long time (e.g., several minutes) can I be sure that only one instance of the consumer will receive the message?A queue message will only be delivered and consumed by 1 consumer.
    2. If a consumer is in step 3 and a catastrophic failure occurs (e.g., the JVM or server it is running on crashes) the message will never be acknowledged, but the session will not be shut down in an orderly fashion, either. Will the message that was received but never acknowledged eventually be delivered to another copy of the consumer?Yes.
    3. If step three takes a very long time (hours or days, rather than minutes), will the broker misinterpret this as a failure of the consumer and deliver the same message to another one of the consumers?No, as long as the consumer's Session or Connection are intact

  • Single queue: concurrent processing of messages in multiple consumers

    Hi,
    I am new to jms . The goal is to  process messages concurrently from a queue in an asynchronous listener's onMessage method  by attaching a listener instance to multiple consumer's with each consumer using its own session and running in a separate thread, that way the messages are passed on to the different consumers for concurrent processing. 
    1) Is it ossible to process messsages concurrently from a single queue by creating multiple consumers ?
    2)  I came up with the below code, but would like to get your thoughts on whether the below code looks correct for what I want to accomplish.  
    import java.io.IOException;
    import java.io.InputStreamReader;
    import java.util.Properties;
    import javax.jms.Connection;
    import javax.jms.ConnectionFactory;
    import javax.jms.Destination;
    import javax.jms.JMSException;
    import javax.jms.Message;
    import javax.jms.MessageConsumer;
    import javax.jms.MessageListener;
    import javax.jms.Session;
    import javax.jms.TextMessage;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import com.walmart.platform.jms.client.JMSConnectionFactory;
    public class QueueConsumer implements Runnable, MessageListener {
      public static void main(String[] args) {
       // Create an instance of the client
        QueueConsumer consumer1 = new QueueConsumer();
        QueueConsumer consumer2 = new QueueConsumer();
        try {
        consumer1.init("oms","US.Q.CHECKOUT-ORDER.1.0.JSON");   //US.Q.CHECKOUT-ORDER.1.0.JSON   is the queue name
        consumer2.init("oms","US.Q.CHECKOUT-ORDER.1.0.JSON");
        }catch( JMSException ex ){
        ex.printStackTrace();
        System.exit(-1);
        // Start the client running
        Thread newThread1 = new Thread(consumer1);
        Thread newThread2 = new Thread(consumer1);
        newThread1.start();newThread2.start();
        InputStreamReader aISR = new InputStreamReader(System.in);
              char aAnswer = ' ';
              do {
                  try {
      aAnswer = (char) aISR.read();
    catch (IOException e)
      // TODO Auto-generated catch block
      e.printStackTrace();
    } while ((aAnswer != 'q') && (aAnswer != 'Q'));
              newThread1.interrupt();
              newThread2.interrupt();
              try {
      newThread1.join();newThread2.join();
      } catch (InterruptedException e) {
      // TODO Auto-generated catch block
      e.printStackTrace();
              System.out
      .println("--------------------exiting main thread------------------------"+Thread.currentThread().getId());
            System.exit(0);
    // values will be read from a resource properties file
    private static String connectionFactoryName = null;
    private static String queueName = null;
    // thread safe object ref
      private static ConnectionFactory qcf = null;
      private static Connection queueConnection = null;
    // not thread safe
      private Session ses = null;
      private Destination queue = null;
      private MessageConsumer msgConsumer = null;
      public static final Logger logger = LoggerFactory
      .getLogger(QueueConsumer.class);
      public QueueConsumer() {
      super();
      public void onMessage(Message msg) {
      if (msg instanceof TextMessage) {
      try {
      System.out
      .println("listener is "+Thread.currentThread().getId()+"--------------------Message recieved from queue is ------------------------"
      + ((TextMessage) msg).getJMSMessageID());
      } catch (JMSException ex) {
      ex.printStackTrace();
      public void run() {
      // Start listening
      try {
      queueConnection.start();
      } catch (JMSException e) {
      e.printStackTrace();
      System.exit(-1);
      while (!Thread.currentThread().isInterrupted()) {
      synchronized (this) {
      try {
      wait();
      } catch (InterruptedException ex) {
      break;
      * This method is called to set up and initialize the necessary Session,
      * destination and message listener
      * @param queue2
      * @param factoryName
      public void init(String factoryName, String queue2) throws JMSException {
      try {
      qcf = new JMSConnectionFactory(factoryName);
      /* create the connection */
      queueConnection = qcf.createConnection();
      * Create a session that is non-transacted and is client
      * acknowledged
      ses = queueConnection.createSession(false,
      Session.CLIENT_ACKNOWLEDGE);
      queue = ses.createQueue(queue2);
      logger.info("Subscribing to destination: " + queue2);
      msgConsumer = ses.createConsumer(queue);
      /* set the listener  */
      msgConsumer.setMessageListener(this);
      System.out.println("Listening on queue " +queue2);
      } catch (Exception e) {
      e.printStackTrace();
      System.exit(-1);
      private static void setConnectionFactoryName(String name) {
      connectionFactoryName = name;
      private static String getQueueName() {
      return queueName;
      private static void setQueueName(String name) {
      queueName = name;

    Hi Mark,
    if the messages are sent with quality of service EO (=exactly once) you can add queues.
    From documentation:
    Netweaver XI -> Runtime -> Processing xml messages -> Queues for asynchronous message processing
    ...For incoming messages you set the parameter EO_INBOUND_PARALLEL from the Tuning category.
    If more than one message is sent to the same receiver, use the configuration parameter EO_OUTBOUND_PARALLEL of the Tuning category to process messages simultaneously in different queues.
    Transaction: SXMB_ADM
    Regards
    Holger

  • Message Driven Bean reading multiple times from a jms queue

    Hi,
    I am facing a strange problem with my message driven bean. Its configured to read message from a jms queue. But sometimes it read the same message multiple times from the jms queue.
    We are using weblogic server 8.1 sp5.
    Please find below our descriptor files
    ejb-jar.xml  
    <ejb-jar>  
      <display-name>ClarifyCRM_Process_Manager_13.1</display-name>  
      <enterprise-beans>  
        <session>  
          <display-name>ProcessManager</display-name>  
          <ejb-name>ProcessManager</ejb-name>  
          <home>com.clarify.procmgr.ejb.ProcessManagerHome</home>  
          <remote>com.clarify.procmgr.ejb.ProcessManagerRemote</remote>  
          <ejb-class>com.clarify.procmgr.ejb.ProcessManagerEJB</ejb-class>  
          <session-type>Stateless</session-type>  
          <transaction-type>Container</transaction-type>  
        </session>  
        <message-driven>  
          <display-name>ProcessManagerListener</display-name>  
          <ejb-name>ProcessManagerListener</ejb-name>  
          <ejb-class>com.clarify.procmgr.ejb.ProcessManagerMDB</ejb-class>  
          <transaction-type>Bean</transaction-type>  
          <acknowledge-mode>Auto-acknowledge</acknowledge-mode>  
          <message-driven-destination>  
            <destination-type>javax.jms.Queue</destination-type>  
          </message-driven-destination>  
        </message-driven>  
      </enterprise-beans>  
      <assembly-descriptor>  
        <container-transaction>  
          <method>  
            <ejb-name>ProcessManager</ejb-name>  
            <method-name>*</method-name>  
          </method>  
          <trans-attribute>Required</trans-attribute>  
        </container-transaction>  
      </assembly-descriptor>  
    </ejb-jar>  
    weblogic-ejb-jar.xml  
    <weblogic-ejb-jar>  
      <weblogic-enterprise-bean>  
        <ejb-name>ProcessManager</ejb-name>  
        <stateless-session-descriptor>  
          <pool>  
            <max-beans-in-free-pool>100</max-beans-in-free-pool>  
            <initial-beans-in-free-pool>10</initial-beans-in-free-pool>  
          </pool>  
        </stateless-session-descriptor>  
        <enable-call-by-reference>False</enable-call-by-reference>  
        <jndi-name>ProcessManagerHome</jndi-name>  
        <dispatch-policy>PMExecuteQueue</dispatch-policy>  
        <remote-client-timeout>0</remote-client-timeout>  
      </weblogic-enterprise-bean>  
      <weblogic-enterprise-bean>  
        <ejb-name>ProcessManagerListener</ejb-name>  
        <message-driven-descriptor>  
          <pool>  
            <max-beans-in-free-pool>100</max-beans-in-free-pool>  
            <initial-beans-in-free-pool>10</initial-beans-in-free-pool>  
          </pool>  
          <destination-jndi-name>clarify.procmgr.jms.queue.Execution</destination-jndi-name>  
          <connection-factory-jndi-name>clarify.procmgr.jms.factories.ExecConnection</connection-factory-jndi-name>  
        </message-driven-descriptor>  
        <enable-call-by-reference>True</enable-call-by-reference>  
        <dispatch-policy>PMListenerExecuteQueue</dispatch-policy>  
        <remote-client-timeout>0</remote-client-timeout>  
      </weblogic-enterprise-bean>  
    </weblogic-ejb-jar>   The MDB is sometimes reading multiple times from clarify.procmgr.jms.queue.Execution
    Also i would like to add here that the connection factory we are using clarify.procmgr.jms.factories.ExecConnection is having the following properties
    ServerAffinity Enabled=true
    XA connection factory enabled=false.
    Please help me out here!!

    Maybe, your MDB "sometimes" throws an Exception in onMessage.
    Check if this happens when you set <max-beans-in-free-pool>1</max-beans-in-free-pool>.

  • Multiple clients to JMS queue

    Hi,
    I have created a JMSQueue in Visual administrator and  able to send /receive messages thru JMS send/recr adapter but need clarification on the below requirement.
    1) How Can I connect JMSQueue in Visual administrator from external systems without using JMS adapter i.e from another WAS JMS queue/other JMS server which is installed on different machine.
    2)How can i connect JMS queue from different clients? Is it possible to post the message into one queue from different clients.
    Thanks in advance.
    Regards,
    Srinivas

    Hi Amol,
    Thank you very much for your reply.
    I need clarification on JMS topics.as per SAP note 856346 (Q.2.1),JMS adapter doen't support JMS topics.
    1)Is it possible to send the same message to multiple receivers by using JMS adapter? (JMS supports point-to-point)
    2)How do we post the message to one queue from different clients? what are the possible ways to achieve the same?
    3)My requirement is: There is a java program , webserver and 100MB size file at source.each time the java program readys say 10MB of data from source file and send it to queue thru webserver and JMS sender adapter reads it from queue and send it to target by using receiver adapter till 100MB data is transfered.Could you please give some idea to achieve this.
    Thanks again for your reply.
    Regards,
    Srinivas

  • JMS Queue Consumers

              Hi,
              I am using WL6.1 SP4 JMS Queues and MDB's. During busy times, the bean(s) can't
              keep up. Number of consumers are always 15 (cosumers total- 30 , consumers high
              - 15 and consumers -15 on Monitoring window) even lot messages are pending in
              the queue. The pool parameters specified in DD are as below
              <pool>
              <max-beans-in-free-pool>30</max-beans-in-free-pool>
              <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
              </pool>
              Can some one help me out.
              Thanks in adv,
              Dp
              

    As far as I know, these are the only two parms that effect
              MDB instance creation on 6.1. I suggest:
              1) increase the values higher to see what happens
              2) make sure to reboot (these values are not dynamic)
              3) force server to thread dump to ensure that the extra threads
              are getting created and that the MDBs are running in
              the thread pool that your are increasing...
              4) post to the weblogic.ejb newsgroup, which "owns" mdbs
              5) contact customer support
              Tom
              DP wrote:
              > Hi,
              >
              > I increased this thread pool size to 25.
              > Now the max-beans-in-free-pool is 20.
              > Still it is not increasing the beans count above 15.
              >
              > DP
              >
              > Tom Barnes <[email protected]> wrote:
              >
              >>MDBs run in the main "default execute" thread pool, which has a
              >>default size of 15. This is the limit you are running into.
              >>You can configure a server's thread pool size on the console.
              >>
              >>Note that since this thread pool is used for other server work,
              >>the MDB max-beans-in-free-pool should be configured to something
              >>somewhat less that the "default execute" thread pool size. This
              >>prevents starvation dead-locks...
              >>
              >>Tom
              >>
              >>DP wrote:
              >>
              >>>Hi,
              >>>
              >>>I am using WL6.1 SP4 JMS Queues and MDB's. During busy times, the
              >>
              >>bean(s) can't
              >>
              >>>keep up. Number of consumers are always 15 (cosumers total- 30 , consumers
              >>
              >>high
              >>
              >>>- 15 and consumers -15 on Monitoring window) even lot messages are
              >>
              >>pending in
              >>
              >>>the queue. The pool parameters specified in DD are as below
              >>>
              >>><pool>
              >>> <max-beans-in-free-pool>30</max-beans-in-free-pool>
              >>> <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
              >>> </pool>
              >>>
              >>>Can some one help me out.
              >>>
              >>>Thanks in adv,
              >>>Dp
              >>
              >
              

  • Connecting to multiple JMS queues

    Hi,
    I need to connect to multiple JMS queues that all have different username/passwords however I'm struggling to find where to add these details.
    In the past we have used the args -Dtibco.default.user=xyz -Dtibco.default.password=1234 on the Server Start tab when connecting to a single queue.
    Clearly this won't work for multiple queues.
    I have tried adding the details on the bridge source but it doesn't seem to make any difference. Any ideas?
    Thanks
    Willy

    Hi Willy,
    This is definitely the week for interop questions.
    There are two opportunities that I know of to pass username and password on a bridge source destination. There are the "username" and "password" attributes, which I assume would work in most cases. Not sure. There are also the JNDI properties, presumably via the standard strings "java.naming.security.principal" and "java.naming.security.credentials".
    It would be interesting to see the full stack trace that your getting.
    Tom
    PS. It's been my experience that many applications don't need to use a bridge for retreiving foreign vendor messages as they can simply receive from foreign vendors directly. For example, via a combination of MDBs and the Foreign JMS facility. For more information see [ Integrating Remote JMS Providers | http://download.oracle.com/docs/cd/E12839_01/web.1111/e13727/interop.htm#JMSPG553 ].

  • Multiple Messages in Same JMS queue

    Hello,
    I have interfaces in which different xml messages from the same sender system will be placed in the same MQ queue, is there a way that XI JMS sender channel can differentiate the xml messages based on the payload?
    I can create a single communication channel, but the outbound message interface I cannot create a common structure because the xml messages are huge and there will be future interfaces following the same architecture.
    1. How can I route in interface determination based on the context in the inbound msg interface?
    2. What can I provide as Message interface for the outbound?
    3. MessageSelector attribute in Adapter specific properties - any ideas on this? - I can select this in the condition context in interface determination - can I give any values here to differentiate msges?
    4. Value mapping - is it possible to define the sender message interface through this?
    Any idea is appreciated..THank you..

    Hi Thanujja,
    We have recently completed a project that had this requirement too. We made use of the MessageSelector to solve this problem. You'll need to make use of some advanced (advanced tab)settings in the comm channel. Basically you want to add Additional JMS Message Properties. You can add up to 10 additonal JMS Properties.
    Let's say you've added a property called MESTYP. You then need to get the sender to populate the MESTYP property with a text value for each IDoc involved e.g. DELVRY. You would then set your JMS Message Selector field as follows: MESTYP='DELVRY'.
    You'll have a comm channel for each IDoc. These comm channels will then connect to the JMS Queue & only pick up messages that meet the criteria at set in the Message Selector.
    There was one other problem that encountered with Message Selector, we were on XI version 7.0, the Message Selector was working intermittently & then we applied SAP Note 1256636 & upgraded to 7.01. Everything is working fine after that.
    Trevor

  • JMS queue consumer challenge

    Hi there,
              I have met a pretty challenging problem in JMS queue consumer and
              would like to know if any JMS lovers in the group know about it.
              We have queue receiver listening on queue which contains a number of
              mugs.
              Once a msg is received (onMessage returns), the msg is handed over to
              a worker thread from a thread pool.
              Essentially there are two parts of the problem:
              1. We want kind of flow control - only x number of msg can be
              processed at a given time. This can be resolved by using semaphore.
              However, there might be better solution out there. Anyhow, this is
              less an issue than the second part -
              2. As we know client_acknowledge happens at the session level:
              Acknowledging a consumed message automatically acknowledges the
              receipt of all messages that have been consumed by its session. For
              example, if a message consumer consumes ten messages and then
              acknowledges the fifth message delivered, all ten messages are
              acknowledged. 
              -- this is the problem -- we want to acknowledge each msg
              individually so that only the processed msg is acknowledged although
              there are x number of msg being retrieved. By doing that we won't lost
              any msg in case the JMS client crashes.
              It is a challenge, isn't it? Might well not be one for you, if you
              know the trick. If you do, could you share with us? Thanks a lot.
              Mike
              

    Just to be clear, I favor (2), where each worker thread has its own session and
              consumer.
              This naturally throttles, as there are only as many outstanding messages as
              worker-threads.
              BTW, be aware that it is against spec, and dangerous, to call acknowledge()
              outside of
              onMessage() - as this multi-threads the Session and Session's are not thread
              safe.
              Tom
              Tom Barnes wrote:
              > Actually you both are correct. The ack behavior is configurable on the
              > connection factory via the "AcknowledgePolicy", where the default is
              > what the spec requires (ack-all). Prior to 6.1
              > the behavior was what one would expect (ack-before).
              >
              > As for how to solve the problem at hand. I can think of three approaches:
              >
              > (1) use the current async consumer but set the ack-policy
              > to ack-before, and defer acknowledging a msg until all msgs before
              > it have finished their processing
              >
              > (2) use multiple synchronous consumers, one consumer per defered msg
              >
              > (3) use a single synchronous consumer, but dequeue transactionally,
              > one transaction per msg. suspend the transaction, then have
              > the worker thread resume the transaction once it finishes processing
              > the message and call commit. (Take care that the default
              > tran timeout is 30 seconds.)
              >
              > Shean-Guang Chang wrote:
              >
              > > Just to correct one assumption. Ack the fifth message will not ack message
              > > received after that (e.g. message 6, 7, 8, etc...). At least not WLS JMS.
              > > If this is not true for you please give details of your client code and
              > > version of WLS JMS you have. Thanks!
              > >
              > > "Mike" <[email protected]> wrote in message
              > > news:[email protected]...
              > > > Hi there,
              > > >
              > > > I have met a pretty challenging problem in JMS queue consumer and
              > > > would like to know if any JMS lovers in the group know about it.
              > > >
              > > > We have queue receiver listening on queue which contains a number of
              > > > mugs.
              > > > Once a msg is received (onMessage returns), the msg is handed over to
              > > > a worker thread from a thread pool.
              > > >
              > > > Essentially there are two parts of the problem:
              > > >
              > > > 1. We want kind of flow control - only x number of msg can be
              > > > processed at a given time. This can be resolved by using semaphore.
              > > > However, there might be better solution out there. Anyhow, this is
              > > > less an issue than the second part -
              > > >
              > > > 2. As we know client_acknowledge happens at the session level:
              > > > Acknowledging a consumed message automatically acknowledges the
              > > > receipt of all messages that have been consumed by its session. For
              > > > example, if a message consumer consumes ten messages and then
              > > > acknowledges the fifth message delivered, all ten messages are
              > > > acknowledged.
              > > > -- this is the problem -- we want to acknowledge each msg
              > > > individually so that only the processed msg is acknowledged although
              > > > there are x number of msg being retrieved. By doing that we won't lost
              > > > any msg in case the JMS client crashes.
              > > >
              > > > It is a challenge, isn't it? Might well not be one for you, if you
              > > > know the trick. If you do, could you share with us? Thanks a lot.
              > > >
              > > > Mike
              

  • JMS/Queue cluster question

              Hi
              I have some very basic cluster questions on JMS Queues. Lets say Q1>I have 3 WLS
              in cluster. I create the queue in only WLS#1 - then all the other WLS (#2 and #3)
              should have a stub in their JNDI tree for the Queue which points to the Queue in
              #1 - right? Basically what I am trying to acheive is to have the queue in one server
              and all the other servers have a pointer to it - I beleive this is possible in WLS
              cluster - right??
              Q2> Is there any way a client to the queue running on a WLS can tell whether the
              Queue handle its using is local (ie in the same server) or remote. Is the API createQueue(./queuename)
              going to help here??
              Q3>Is there any way to create a Queue dynamically - I guess JMX is the answer -right?
              But I will take this question a bit further - lets say Q1 answer is yes. In this
              case if server #1 crashes - then #2 and #3 have no Queues. So if they try to create
              a replica of the Queue (as on server#1) - pointing to the same filestore - can they
              do it?? - I want only one of them to succed in creating the Queue and also the Queue
              should have all the data of the #1 Queue (1 to 1 replica).
              All I want is the concept of primary and secondary queue in a cluster. Go on using
              the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession replication
              concept in clusters. My cluster purpose is more for failover rather than loadbalancing.
              TIA
              Anamitra
              

              Anamitra wrote:
              > Hi Tom
              > 7.0 is definitely an option for me. So lets take the scenarion on case of JMS cluster
              > and 7.0.
              >
              > I do not understand what u mean by HA framework?
              An HA framework is a third party product that can be used to automatically restart a failed server
              (perhaps on a new machine), and that will guarantee that the same server isn't started in two
              different places (that would be bad). There are few of these HA products, "Veritas" is one of
              them. Note that if you are using JMS file stores or transactions, both of which depend on the disk,
              you must make sure that the files are available on the new machine. One approach to this is to use
              what is known as a "dual-ported" disk.
              > If I am using a cluster of 3 WLS
              > 7.0 servers - as u have said I can create a distrubuted Queue with a fwd delay attribute
              > set to 0 if I have the consumer only in one server say server #1.
              > But still if the server #1 goes down u say that the Queues in server #2 and server
              > #3 will not have access to the messages which were stuck in the server #1 Queue when
              > it went down -right?
              Right, but is there a point in forwarding the messages to your consumer's destination if your
              application is down?
              If your application can tolerate it, you may wish to consider allowing multiple instances of it (one
              per physical destination). That way if something goes down, only those messages are out-of-business
              until the application comes back up...
              >
              >
              > Why cant the other servers see them - they all point to the same store right??
              > thanks
              > Anamitra
              >
              Again, multiple JMS servers can not share a store. Nor can multiple stores share a file. That will
              cause corruption. Multiple stores CAN share a database, but can't use the same tables in the
              database.
              Tom
              >
              > Tom Barnes <[email protected]> wrote:
              > >
              > >
              > >Anamitra wrote:
              > >
              > >> Hi
              > >> I have some very basic cluster questions on JMS Queues. Lets say Q1>I
              > >have 3 WLS
              > >> in cluster. I create the queue in only WLS#1 - then all the other WLS
              > >(#2 and #3)
              > >> should have a stub in their JNDI tree for the Queue which points to the
              > >Queue in
              > >> #1 - right?
              > >
              > >Its not a stub. But essentially right.
              > >
              > >> Basically what I am trying to acheive is to have the queue in one server
              > >> and all the other servers have a pointer to it - I beleive this is possible
              > >in WLS
              > >> cluster - right??
              > >
              > >Certainly.
              > >
              > >>
              > >> Q2> Is there any way a client to the queue running on a WLS can tell whether
              > >the
              > >> Queue handle its using is local (ie in the same server) or remote. Is
              > >the API createQueue(./queuename)
              > >> going to help here??
              > >
              > >That would do it. This returns the queue on the CF side of the established
              > >Connection.
              > >
              > >>
              > >> Q3>Is there any way to create a Queue dynamically - I guess JMX is the
              > >answer -right?
              > >> But I will take this question a bit further - lets say Q1 answer is yes.
              > >In this
              > >> case if server #1 crashes - then #2 and #3 have no Queues. So if they
              > >try to create
              > >> a replica of the Queue (as on server#1) - pointing to the same filestore
              > >- can they
              > >> do it??
              > >> - I want only one of them to succed in creating the Queue and also the
              > >Queue
              > >> should have all the data of the #1 Queue (1 to 1 replica).
              > >
              > >No. Not possible. Corruption city.
              > >Only one server may safely access a store at a time.
              > >If you have an HA framework that can ensure this atomicity fine, or are
              > >willing
              > >to ensure this manually then fine.
              > >
              > >>
              > >>
              > >> All I want is the concept of primary and secondary queue in a cluster.
              > >Go on using
              > >> the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession
              > >replication
              > >> concept in clusters. My cluster purpose is more for failover rather than
              > >loadbalancing.
              > >
              > >If you use 7.0 you could use a distributed destination, with a high weight
              > >on the destination
              > >you want used most. Optionally, 7.0 will automatically forward messages
              > >from distr. dest
              > >members that have no consumers to those that do.
              > >
              > >In 6.1 you can emulate a distributed destination this way (from an upcoming
              > >white-paper):
              > >Approximating Distributed Queues in 6.1
              > >
              > >If you wish to distribute the destination across several servers in a cluster,
              > >use the distributed
              > >destination features built into WL 7.0. If 7.0 is not an option, you can
              > >still approximate a simple
              > >distributed destination when running JMS servers in a &#8220;single-tier&#8221;
              > configuration.
              > > Single-tier indicates
              > >that there is a local JMS server on each server that a connection factory
              > >is targeted at. Here is a
              > >typical scenario, where producers randomly pick which server and consequently
              > >which part of the
              > >distributed destination to produce to, while consumers in the form of MDBs
              > >are pinned to a particular
              > >destination and are replicated homogenously to all destinations:
              > >
              > >· Create JMS servers on multiple servers in the cluster. The servers will
              > >collectively host the
              > >distributed queue &#8220;A&#8221;. Remember, the JMS servers (and WL servers) must
              > >be named differently.
              > >
              > >· Configure a queue on each JMS server. These become the physical destinations
              > >that collectively become
              > >the distributed destination. Each destination should have the same name
              > >"A".
              > >
              > >· Configure each queue to have the same JNDI name &#8220;JNDI_A&#8221;, and also
              > take
              > >care to set the destination&#8217;s
              > >&#8220;JNDINameReplicated&#8221; parameter to false. The &#8220;JNDINameReplicated&#8221;
              > parameter
              > >is available in 7.0, 6.1SP3
              > >or later, or 6.1SP2 with patch CR061106.
              > >
              > >· Create a connection factory, and target it at all servers that have a
              > >JMS server with &#8220;A&#8221;.
              > >
              > >· Target the same MDB pool at each server that has a JMS server with destination
              > >&#8220;A&#8221;, configure its
              > >destination to be &#8220;JNDI_A&#8221;. Do not specify a connection factory URL
              > when
              > >configuring the MDB, as it can
              > >use the server&#8217;s default JNDI context that already contains the destination.
              > >
              > >· Producers look up the connection factory, create a connection, then a
              > >session as usual. Then producers
              > >look up the destination by calling javax.jms.QueueSession.createQueue(String).
              > > The parameter to
              > >createQueue requires a special syntax, the syntax is &#8220;./<queue name>&#8221;,
              > so
              > >&#8220;./A&#8221; works in this example.
              > >This will return a physical destination of the distributed destination that
              > >is local to the producer&#8217;s
              > >connection. This syntax is available on 7.0, 6.1SP3 or later, and 6.1SP2
              > >with patch CR072612.
              > >
              > >This design pattern allows for high availability, as if one server goes
              > >down, the distributed destination
              > >is still available and only the messages on that one server become unavailable.
              > > It also allows for high
              > >scalability as speedup is directly proportional to the number of servers
              > >on which the distributed
              > >destination is deployed.
              > >
              > >
              > >
              > >>
              > >> TIA
              > >> Anamitra
              > >
              > >
              > ><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
              > ><html>
              > >Anamitra wrote:
              > ><blockquote TYPE=CITE>Hi
              > ><br>I have some very basic cluster questions on JMS Queues. Lets say Q1>I
              > >have 3 WLS
              > ><br>in cluster. I create the queue in only WLS#1 - then all the other WLS
              > >(#2 and #3)
              > ><br>should have a stub in their JNDI tree for the Queue which points to
              > >the Queue in
              > ><br>#1 - right?</blockquote>
              > >Its not a stub. But essentially right.
              > ><blockquote TYPE=CITE>Basically what I am trying to acheive is to have
              > >the queue in one server
              > ><br>and all the other servers have a pointer to it - I beleive this is
              > >possible in WLS
              > ><br>cluster - right??</blockquote>
              > >Certainly.
              > ><blockquote TYPE=CITE>
              > ><br>Q2> Is there any way a client to the queue running on a WLS can tell
              > >whether the
              > ><br>Queue handle its using is local (ie in the same server) or remote.
              > >Is the API createQueue(./queuename)
              > ><br>going to help here??</blockquote>
              > >That would do it. This returns the queue on the
              > >CF side of the established Connection.
              > ><blockquote TYPE=CITE>
              > ><br>Q3>Is there any way to create a Queue dynamically - I guess JMX is
              > >the answer -right?
              > ><br>But I will take this question a bit further - lets say Q1 answer is
              > >yes. In this
              > ><br>case if server #1 crashes - then #2 and #3 have no Queues. So if they
              > >try to create
              > ><br>a replica of the Queue (as on server#1) - pointing to the same filestore
              > >- can they
              > ><br>do it?? <br>
              > >- I want only one of them to succed in creating the Queue and also the
              > >Queue
              > ><br>should have all the data of the #1 Queue (1 to 1 replica).</blockquote>
              > >No. Not possible. Corruption city.
              > ><br>Only one server may safely access a store at a time.
              > ><br>If you have an HA framework that can ensure this atomicity fine, or
              > >are willing
              > ><br>to ensure this manually then fine.
              > ><blockquote TYPE=CITE>
              > ><p>All I want is the concept of primary and secondary queue in a cluster.
              > >Go on using
              > ><br>the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession
              > >replication
              > ><br>concept in clusters. My cluster purpose is more for failover rather
              > >than loadbalancing.</blockquote>
              > >If you use 7.0 you could use a distributed destination, with a high weight
              > >on the destination
              > ><br>you want used most. Optionally, 7.0 will automatically
              > >forward messages from distr. dest
              > ><br>members that have no consumers to those that do.
              > ><p><i>In 6.1 you can emulate a distributed destination this way (from an
              > >upcoming white-paper):</i>
              > ><br><i>Approximating Distributed Queues in 6.1</i><i></i>
              > ><p><i>If you wish to distribute the destination across several servers
              > >in a cluster, use the distributed destination features built into WL 7.0.
              > >If 7.0 is not an option, you can still approximate a simple distributed
              > >destination when running JMS servers in a &#8220;single-tier&#8221; configuration.
              > >Single-tier indicates that there is a local JMS server on each server that
              > >a connection factory is targeted at. Here is a typical scenario,
              > >where producers randomly pick which server and consequently which part
              > >of the distributed destination to produce to, while consumers in the form
              > >of MDBs are pinned to a particular destination and are replicated homogenously
              > >to all destinations:</i><i></i>
              > ><p><i>· Create JMS servers on multiple servers in the cluster.
              > >The servers will collectively host the distributed queue &#8220;A&#8221;. Remember,
              > >the JMS servers (and WL servers) must be named differently.</i><i></i>
              > ><p><i>· Configure a queue on each JMS server. These become
              > >the physical destinations that collectively become the distributed destination.
              > >Each destination should have the same name "A".</i><i></i>
              > ><p><i>· Configure each queue to have the same JNDI name &#8220;JNDI_A&#8221;,
              > >and also take care to set the destination&#8217;s &#8220;JNDINameReplicated&#8221;
              > parameter
              > >to false. The &#8220;JNDINameReplicated&#8221; parameter is available in
              > >7.0, 6.1SP3 or later, or 6.1SP2 with patch CR061106.</i><i></i>
              > ><p><i>· Create a connection factory, and target it at all servers
              > >that have a JMS server with &#8220;A&#8221;.</i><i></i>
              > ><p><i>· Target the same MDB pool at each server that has a JMS server
              > >with destination &#8220;A&#8221;, configure its destination to be &#8220;JNDI_A&#8221;.
              > >Do not specify a connection factory URL when configuring the MDB, as it
              > >can use the server&#8217;s default JNDI context that already contains the destination.</i><i></i>
              > ><p><i>· Producers look up the connection factory, create a connection,
              > >then a session as usual. Then producers look up the destination by
              > >calling javax.jms.QueueSession.createQueue(String). The parameter
              > >to createQueue requires a special syntax, the syntax is &#8220;./<queue name>&#8221;,
              > >so &#8220;./A&#8221; works in this example. This will return a physical
              > >destination of the distributed destination that is local to the producer&#8217;s
              > >connection. This syntax is available on 7.0, 6.1SP3 or later,
              > >and 6.1SP2 with patch CR072612.</i><i></i>
              > ><p><i>This design pattern allows for high availability, as if one server
              > >goes down, the distributed destination is still available and only the
              > >messages on that one server become unavailable. It also allows
              > >for high scalability as speedup is directly proportional to the number
              > >of servers on which the distributed destination is deployed.</i>
              > ><br><i></i>
              > ><br><i></i>
              > ><blockquote TYPE=CITE>
              > ><br>TIA
              > ><br>Anamitra</blockquote>
              > ></html>
              > >
              > >
              

  • Cleanup JMS queue/topic messages

              how do I clean up all messages left on a queue/topic ? thx.
              

    There is no purge command.
              In 8.1, delete and recreate the destination via the console,
              JMX, or extensions.JMSHelper, the JMS
              server doesn't even need to be booted. A timestamp
              in the destination configuration is automatically set to
              let JMS detect that the destination is a new version.
              In 7.0, delete the queue, shutdown the JMS server,
              reboot the JMS server, and then recreate the destination.
              In any version, shutting down the JMS server will delete
              non-persistent messages.
              You can delete topic subscriptions via the console.
              You can write a simple JMS client to drain the destination
              by consuming messages. (Multi-thread multiple consumers to
              speed this up considerably.)
              Queen Tsao wrote:
              > how do I clean up all messages left on a queue/topic ? thx.
              

  • Doubt in Flat File Format in sender jms queue?

    Hi All,
    I have a JMS-IDOC scenario with Content Conversion. The input file can have  fixed length, multiple records.
    Each record comes in a newline.
    But , heard, one  cannot place a multiline data as a single message in the JMS Queue.
    Each new line of the data will be placed as a single separate message.
    so for every line , a new xml message gets created and the scenario gets triggered.
    But I want the all records (lines)  in a single xml message
    Could someone tell me what is to be done?

    > But , heard, one cannot place a multiline data as a single message in the JMS Queue.
    That is wrong. You can put anything in the JMS queue, even binary.
    Regards
    Stefan

  • MDBs in 9.1 continue to consume JMS queues even after being deleted

    <b>We have an MDB application that reads a batch message off of a JMS queue, archives it in a database, parses the batch message into individual messages and writes them onto other JMS queues to be consumed by another application. Everything was running fine in Weblogic 8.1.5. However, due to problems with XA drivers and the MSDTC(predictable SQL server crashes), we decided to upgrade to Weblogic 9.1 to take advantage of the LLR option.</b>
              <b>First, we had an issue where our MDBs were causing the following exception:</b>
              <i>####<May 26, 2006 7:42:12 PM EDT> <Error> <JMX> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686932991> <BEA-149500> <An exception occurred while registering the MBean null.
              java.lang.IllegalArgumentException: Registered more than one instance with the same objectName : com.bea:ServerRuntime=wltest1,MessageDrivenEJBRuntime=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,Name=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,ApplicationRuntime=DataBrokerEAR1_2,Type=EJBPoolRuntime,EJBComponentRuntime=DataBrokerEJB new:[email protected] existing weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl@7db003
                   at weblogic.management.jmx.ObjectNameManagerBase.registerObject(ObjectNameManagerBase.java:146)
                   at weblogic.management.mbeanservers.internal.WLSObjectNameManager.lookupObjectName(WLSObjectNameManager.java:133)
                   at weblogic.management.jmx.modelmbean.WLSModelMBeanFactory.registerWLSModelMBean(WLSModelMBeanFactory.java:86)
                   at weblogic.management.mbeanservers.internal.RuntimeMBeanAgent$1.registered(RuntimeMBeanAgent.java:104)
                   at weblogic.management.provider.internal.RegistrationManagerImpl.invokeRegistrationHandlers(RegistrationManagerImpl.java:205)
                   at weblogic.management.provider.internal.RegistrationManagerImpl.register(RegistrationManagerImpl.java:85)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:320)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:257)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:222)
                   at weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl.<init>(EJBPoolRuntimeMBeanImpl.java:32)
                   at weblogic.ejb.container.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:49)
                   at weblogic.ejb.container.manager.MessageDrivenManager.initialize(MessageDrivenManager.java:503)
                   at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:120)
                   at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:146)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createMDManager(MessageDrivenBeanInfoImpl.java:1481)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createDDMDManagers(MessageDrivenBeanInfoImpl.java:1378)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.onDDMembershipChange(MessageDrivenBeanInfoImpl.java:1285)
                   at weblogic.jms.common.CDS$DD2Listener.listChange(CDS.java:454)
                   at weblogic.jms.common.CDSServer$DDHandlerChangeListener.statusChangeNotification(CDSServer.java:167)
                   at weblogic.jms.dd.DDHandler.callListener(DDHandler.java:318)
                   at weblogic.jms.dd.DDHandler.callListeners(DDHandler.java:344)
                   at weblogic.jms.dd.DDHandler.run(DDHandler.java:282)
                   at weblogic.jms.common.SerialScheduler.run(SerialScheduler.java:37)
                   at weblogic.work.ExecuteRequestAdapter.execute(ExecuteRequestAdapter.java:21)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
              >
              ####<May 26, 2006 7:42:13 PM EDT> <Info> <EJB> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686933069> <BEA-010060> <The Message-Driven EJB: RhapsodyMDB has connected/reconnected to the JMS destination: weblogic.jms.DMB_BEAN_QUEUE.></i>
              <b>
              Generally this happend after there were cluster communication issues. Multi-cast messages were lost and our MDB reconnects to the JMS queues as indicated by the below log:</b>
              <i>####<May 30, 2006 5:19:06 PM EDT> <Info> <EJB> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '54' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1149023946040> <BEA-010060> <The Message-Driven EJB: DataBrokerMDB has connected/reconnected to the JMS destination: weblogic.jms.PHINMS_DMB_QUEUE.>
              ####<May 30, 2006 5:19:10 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023950228> <BEA-000112> <Removing RAPBEA3S jvmid:720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S from cluster view due to timeout.>
              ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951009> <BEA-000115> <Lost 2 multicast message(s).>
              ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951040> <BEA-000111> <Adding RAPBEA3S with ID 720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S to cluster: DMBstg_cluster view.></i>
              <b>
              This would cause the queues to eventually have hundreds of consumers and cause the server to fail.
              Basically, it seems as though the MDBs that are supposed to stop continue and attempt to process, while new threads connect to the JMS queues.
              I tried undeploying our application and deleted it from the configuration. However there were consumers still on the respective queues and when I sent messages, I got an error indicating a "Class Not Found exception" due to the fact that the EJB was undeployed and deleted from the configuration, however the MDB component was not and continued to listen for messages. In 8.1.5, as soon as the application was undeployed, there were zero consumers on the JMS queues.
              I have read the posts about a soon to be released fix that would have the MDBs connect only to the queues locally and not go out the the cluster. Would this fix my issue?
              Is there something in the deployment descriptor to configure that will cause it to disconnect and now spawn so many consumers to the JMS queues?
              Why is it that the number of MDB consumers on the JMS queues stayed static in 8.1.5, but they are erratic in 9.1 even after I set our 9.1 server to use the 8.1.5 execute queue policy. Help would be much appreciated.</b>

    I recommend contacting customer support. There's a known problem with MDBs listening to distributed destinations that are local to the same cluster as the MDB, you're problem may be related (the clue is that the stack trace contains jms.dd.DDHandler.callListeners()). The problem is that the MDB connects to all physical queues in a distributed destination rather than just the local queue.
              Tom

Maybe you are looking for