Concurrent MDBs

Hi!
          SUN JMS specs say, that "The session used to create the message consumer
          serializes the execution of all message listeners registered with the
          session. At any time, only one of the session's message listeners is
          running." As I understand this statement, I can be sure, that for particular
          session only one listener is active in any moment of time.
          Further statement says that "In the J2EE 1.3 platform, a message-driven bean
          is a special kind of message listener." And, "Like a stateless session
          bean, a message-driven bean can have many interchangeable instances running
          at the same time. The container can pool these instances to allow streams of
          messages to be processed concurrently. Concurrency can affect the order in
          which messages are delivered, so you should write your application to handle
          messages that arrive out of sequence. "
          So, in J2EE real JMS listener is located somewhere in the app server and
          gets messages in serialized manner, but it passes these messages to MDBs,
          which can run concurrently?
          The questions are:
          * does serialized mode of standard JMS listeners ensure the correct message
          order?
          * how I can serialize message processing, using MDBs? I use WLS7, if it may
          help. I guess I can tune server to use only one instance of MDB... Any other
          approaches?
          

There have been several posts on this topic in the past. If I remember
          correctly, while you will be able to maintain order integrity with a single
          consumer or MDB instance, it would work only as long as there are no
          rollbacks. There is no guarantee of ordering in the event of rollbacks.
          Thanks,
          Adarsh
          "Michael Jouravlev" <[email protected]> wrote in message
          news:[email protected]...
          > Hi!
          >
          > SUN JMS specs say, that "The session used to create the message consumer
          > serializes the execution of all message listeners registered with the
          > session. At any time, only one of the session's message listeners is
          > running." As I understand this statement, I can be sure, that for
          particular
          > session only one listener is active in any moment of time.
          >
          > Further statement says that "In the J2EE 1.3 platform, a message-driven
          bean
          > is a special kind of message listener." And, "Like a stateless session
          > bean, a message-driven bean can have many interchangeable instances
          running
          > at the same time. The container can pool these instances to allow streams
          of
          > messages to be processed concurrently. Concurrency can affect the order in
          > which messages are delivered, so you should write your application to
          handle
          > messages that arrive out of sequence. "
          >
          > So, in J2EE real JMS listener is located somewhere in the app server and
          > gets messages in serialized manner, but it passes these messages to MDBs,
          > which can run concurrently?
          >
          > The questions are:
          > * does serialized mode of standard JMS listeners ensure the correct
          message
          > order?
          > * how I can serialize message processing, using MDBs? I use WLS7, if it
          may
          > help. I guess I can tune server to use only one instance of MDB... Any
          other
          > approaches?
          >
          >
          >
          >
          

Similar Messages

  • Increase Number of Concurrent MDBs

    We are using WL 10.3.3. The heaviest load of the app is the JMS message processing. With the default work manager, the maximum number of concurrent MDBs is 16. We need to increase the MDB instances to a larger number. What is the best way to accomplish this?
    I did the followings, but it does seem to be working -
    1. Created an application I set up a work manager with MaxThreadsConstraint is set to 30
    2. Added the work mananger's name to the Dispatch Policy of the message bean configuration
    But on the Monitoring/Workload tab of the message driven bean, neither the work manager nor the Max Threads Constraint showed up. And the maximum bean instances stayed at the 16.
    What is missing there?
    Thanks,
    Hong

    Hi ,
    You have to create a custom work manager and then you have to associate this customer work manager to the dispatch policy of the MDB to increase the threads.
    Following links would surely help you as TomB has explained the same issue very well, do have a look at them.
    Re: WorkManager Max thread constraints not applied to MDB
    Questions Regarding MDB
    1 - Set the MDB's dispatch-policy to reference a custom work manager (not the default work manager)
    2 - Set the MDB's max-beans-free-pool to higher than 16 (default is something like 1000)
    3 - Configure the custom work manager with max threads constraint of higher than 16.However in the first link as its suggest the values for "max-beans-free-pool" and "max threads constraint" should be more then 16 because that's the default value, hence I would suggest you to keep both these value same BUT more then 16.
    Regards,
    Ravish Mody
    http://middlewaremagic.com/weblogic/
    Come, Join Us and Experience The Magic…

  • MDB Transaction

    Hi,
    I'm having some issues in same cases with MDB transactions on WL. I have an MDB deployed on a 9.2 WL defined as a CMP with auto-acknowledge in the EJB descriptor (using EJB 2.1 standards) which listens on a queue which is defined in the local WL JMS module and mapped to an external Tibco EMS queue.
    Used descriptor configuration :
    <messaging-type>javax.jms.MessageListener</messaging-type>
    <transaction-type>Container</transaction-type>
    <message-destination-type>javax.jms.Queue</message-destination-type>
    <activation-config>
    <activation-config-property>
    <activation-config-property-name>destinationType</activation-config-property-name>
    <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
    <activation-config-property-name>acknowledgeMode</activation-config-property-name>
    <activation-config-property-value>Auto-acknowledge</activation-config-property-value>
    </activation-config-property>
    </activation-config>
    The MDB processes the message, accesses a DB and sends it of the an external system. When no exception happened the MDB method finishes and normally the container acknowledges
    This all works great untill we put some load on the queue. Sometimes we note that a JMS message gets stuck in the input queue when lots of messages are being put on the input queue. We can trace that such messages actually were picked up by the MDB and processed to a certain extend.
    Sometimes the processing log trace just stops in the middle of processing. Sometimes the entire processing log trace is present. However the JMS messages are kept in the input queue and seem to locked (they can't be flushed out as long as the component is still running).
    It looks like the messages are awaiting acknowledgement from the WL container manager but somehow the transaction got lost and never got back to the external EMS to acknowledge the message in the input queue.
    I was wondering if there is a way to monitor CMP transactions or the status of the container manager? As far as I know the container manager always tries to contact the remote EMS server to acknowledge the message in this setup. What would happen if the remote EMS server would be overloaded and could not respond back to the WL container manager to confirm message acknowledgment?

    Thanks for the reply. There are no errors what so ever regarding MDB issues. Not in the weblogic / console logging, nor in the logging of the component itself.
    The MDB itself is setup to have 16 concurrent beans per component deployment. The component is clustered over 4 server instances. So there are quite some concurrent MDBs running. However since the messages get stuck for weeks eventhough the component only has bursts of messages to process, one would think that the the stuck messages would be processed whenever the component has some spare time (which it has a lot between the bursts).
    Therefor i doubt it has anything to do with too little MDBs running. But frankly I have no idea what's wrong.

  • Not all JMS consumers are created equal

    Hi,
    I am experiencing a very strange problem with weblogic 9.2 JMS.
    I am using JMS as flow control in an application that allows our users to import data into our application.
    the data to be imported varies in size from 100's of records to many hundred thousands of records.
    JMS feed a MDB that takes the request and imports the data. The DD allows to 10 concurrent MDB's to service the requests.
    The problem arises when the 11'th and 12th request comes in. Instead of waiting for the first availibe MDB to service the requests they seems to be put into the queue of the MDB that was started first. If this MDB is in the process of importing a very large file request 11 and 12 will sit and wait until the large one is done even though there are other MDB's that are idle.
    I am hoping that there is an easy fix for this, but for the life of me, I cant seem to find it.
    The DD for the MDB looks as follows
    <weblogic-enterprise-bean>
    <ejb-name>RuleEngineMDB</ejb-name>
    <message-driven-descriptor>
    <pool>
    <max-beans-in-free-pool>10</max-beans-in-free-pool>
    <initial-beans-in-free-pool>10</initial-beans-in-free-pool>
    </pool>
    <destination-jndi-name>com.company.product.RuleEngineRequestQueue</destination-jndi-name>
    </message-driven-descriptor>
    </weblogic-enterprise-bean>
    the queue is defined in Weblog as
    <queue name="RuleEngineReque
    stQueue">
    <sub-deployment-name>MyJMSServer</sub-deployment-name>
    <delivery-params-overrides>
    <delivery-mode>Non-Persistent</delivery-mode>
    </delivery-params-overrides>
    <message-logging-params>
    <message-logging-enabled>true</message-logging-enabled>
    <message-logging-format>%header%,%properties%,%body%</message-logging-format>
    </message-logging-params>
    <jndi-name>com.company.product.RuleEngineRequestQueue</jndi-name>
    </queue>
    regards,
    Lars Hansson
    CTO Compost Marketing AB.

    A little more detail: You will need to configure and target a custom conection factory with "message maximum" set to 1 (the default is 10), and then modify the MDB descriptor to reference the JNDI name of the custom connection factory. The connection factory should be targeted to the entire cluster, and must be targeted to the same cluster that hosts distributed queue. If the MDB is transactional, ensure that that the custom connection factory is also "xa enabled".
    Edited by: TomB on Mar 2, 2010 2:44 PM

  • JMS Message Queue - stuck in

    I am on SOA SUITE 11.1.17
    I have a jms queue set up and am able to successfully send messages to it using the SOA JMS Adapter.  I am able to succesfully listen to a queue using a JMS adapter in a different project.
    However, here when I try to "listen" to the queue using a java program, the message is "received" in my java program and processed as it should be.  The java program is running in a while loop, so it stays running.
    On the queue, when the java program reads it, the message is moved to the "Messages Pending" column.  When I kill the java program, the message is returned to the "Messages Current"
    Would anyone have any ideas about this?  We have an existing java based program isn't properly "closing" the message.
    I tried:
    1.  placing msg.acknowledge() in the code, since the documentation states that messages that are in "Messages Pending" have been read, but not acknowledged or committed -- but this does nothing.
    2.  Setting the expiration on the message to 1, but that is a hack.  I would rather fix the problem than use a hack.
    Anyone have any ideas what is wrong?
    Thank you,
    Stuart
    import java.io.IOException;
    import java.io.InputStreamReader;
    import javax.jms.Connection;
    import javax.jms.JMSException;
    import javax.jms.Message;
    import javax.jms.MessageConsumer;
    import javax.jms.MessageListener;
    import javax.jms.Session;
    import javax.jms.TextMessage;
    public class JMSListenAndRespond extends JMSQueueHandler implements MessageListener {
      private Session jmsSession = null;
      private MessageConsumer jmsMessageConsumer = null;
      private Connection jmsConnection = null;
      int counter = 1 ;
      public static void main(String[] args) throws Exception {
        InputStreamReader commandBuffer = null;
        char command = '\0';
          // first listen for any messages
          JmsDataObject q = new JmsDataObject();
          q.setJmsCF("jms/TestConnectionFactory");
          q.setJmsQueue("jms/TestJMSQueue");
          q.setServerPwd("welcome1");
          q.setServerLogin("weblogic");
          q.setUrl("t3://localhost:7101");
          q.setJmsMsg("na -- we are listinging...");
        JMSListenAndRespond lis = new JMSListenAndRespond();
         lis.consumeMessage(q);
        System.out.println("(type q to exit at any time...)\n");
        try {
          // Now just loop, waiting for messages until user types 'q' to quit
          commandBuffer = new InputStreamReader(System.in);
        while (!(command == 'q')) {
           try {
              command = (char)commandBuffer.read();
              System.out.println("Command: "+command);
              lis.stopListening();
            } catch (IOException e) {
              System.err.println("I/O Exception: ");
              e.printStackTrace();
           } //while
        } finally {
                lis.stopListening();
          lis.stopListening();
       public void stopListening() {
        try {
          if (jmsMessageConsumer != null) {
            jmsMessageConsumer.close();
          if (jmsSession != null) {
            jmsSession.close();
          if (jmsConnection != null) {
            jmsConnection.close();
        } catch (JMSException e) {
          System.err.println("Couldn't properly close all resources.\n");
          e.printStackTrace();
      private void prepareToConsumeMessage() {
        // create JMS connection, session, consumer and register listener - then start session
            try {
          // create connection
          jmsConnection = getJmsConnectionFactory().createConnection();
          // create session
          jmsSession =   jmsConnection.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
          jmsMessageConsumer = jmsSession.createConsumer(getJmsDestination());
          // register a message listener (onMessage)
          jmsMessageConsumer.setMessageListener(this);
          // initiate connection - make sure to register your listener first or you might lose messages
          jmsConnection.start();
          System.out.println("\n...listening for message!\n");
        } catch (JMSException e) {
          System.err.println("Problem initializing JMS session");
          e.printStackTrace();
          System.exit(-1);
         * onMessage
         * The callback function invoked upon message reception
      public void onMessage(Message msg) {
        try {
          String msgText;
          if (msg instanceof TextMessage) {
            msgText = ((TextMessage)msg).getText();
            // this method expects a CSV string with the following makeup:
            // firstName,lastName,gender,birthdate,address,city,zipcode,state,insurancePolicyId
            String messageId = msg.getJMSMessageID();
          // code to process goes here.....
          } else {
            // if message is not a TextMessage, attempt a conversion to string
            System.out.println("\n** NEW MESSAGE (" + msg.getClass().getName() +
                               "):\n" +
                msg.toString());
        } catch (JMSException e) {
          e.printStackTrace();
      public void consumeMessage(JmsDataObject q ) {
        initializeJndiProperties(q);
        initializeJNDIandCF(q.getJmsQueue());
        prepareToConsumeMessage();
    import java.util.Properties;
    import javax.jms.Connection;
    import javax.jms.ConnectionFactory;
    import javax.jms.Destination;
    import javax.naming.InitialContext;
    import javax.naming.NamingException;
    public abstract class JMSQueueHandler {
      protected void initializeJNDIandCF(String destinationQueueName) {
        // initialize JNDI context and lookup connection factory and destination
        try {
          // Initialize JNDI context
          jndiContext = new InitialContext(jndiProperties);
        } catch (NamingException e) {
          e.printStackTrace();
        try {
          // lookup JMS connection factory in JNDI
          jmsConnectionFactory =
              (ConnectionFactory)jndiContext.lookup(jndiProperties.getProperty("factory.name"));
          // lookup JMS destination in JNDI
          jmsDestination = (Destination)jndiContext.lookup(destinationQueueName);
        } catch (NamingException e) {
          System.err.println("Problem during the JNDI lookup\n");
          e.printStackTrace();
          System.exit(-1);
      public void initializeJndiProperties(JmsDataObject qdo ) {
        // set JNDI properties
        jndiProperties.put("java.naming.factory.initial","weblogic.jndi.WLInitialContextFactory");
        jndiProperties.put("java.naming.provider.url", qdo.getUrl() );
       // jndiProperties.put("java.naming.security.principal", NAMING_PRINCIPAL);
        jndiProperties.put("java.naming.security.principal", qdo.getServerLogin() ) ;
        //  jndiProperties.put("java.naming.security.credentials", NAMING_CREDENTIAL);
        jndiProperties.put("java.naming.security.credentials", qdo.getServerPwd() );
        //jndiProperties.put("factory.name", JMS_CONNECTION_FACTORY);
        jndiProperties.put("factory.name", qdo.getJmsCF() );
      //protected static final String NAMING_PROVIDER_URL = "t3://localhost:7101";
    //protected static final String NAMING_PRINCIPAL = "weblogic";
    // protected static final String NAMING_CREDENTIAL = "welcome1";
    // protected static final String JMS_CONNECTION_FACTORY = "jms/patientsJmsCF";
    // protected static final String JMS_CONNECTION_FACTORY = "jms/TestConnectionFactory";
      ConnectionFactory jmsConnectionFactory = null;
      Destination jmsDestination = null;
      InitialContext jndiContext = null;
      Properties jndiProperties = new Properties();
      public void setJmsConnectionFactory(ConnectionFactory jmsConnectionFactory) {
        this.jmsConnectionFactory = jmsConnectionFactory;
      public ConnectionFactory getJmsConnectionFactory() {
        return jmsConnectionFactory;
      public void setJmsDestination(Destination jmsDestination) {
        this.jmsDestination = jmsDestination;
      public Destination getJmsDestination() {
        return jmsDestination;

    Thanks for the reply. There are no errors what so ever regarding MDB issues. Not in the weblogic / console logging, nor in the logging of the component itself.
    The MDB itself is setup to have 16 concurrent beans per component deployment. The component is clustered over 4 server instances. So there are quite some concurrent MDBs running. However since the messages get stuck for weeks eventhough the component only has bursts of messages to process, one would think that the the stuck messages would be processed whenever the component has some spare time (which it has a lot between the bursts).
    Therefor i doubt it has anything to do with too little MDBs running. But frankly I have no idea what's wrong.

  • MDB cannot loads enitities if more than 10 concurrent messages are sent tog

    Hello,
    I have seen a weird behavior of the MDB in Jboss or perhaps in transaction management.
    Here is a my scenario
    I have a session bean sb, an entity bean e and a message driven bean mb
    When a request comes to sb , it persists a new entity e and send a message (primary key) to mb
    mb then loads e from the database using one of the findByXX method and does something else.
    If 10 concurrent request comes to sb, 10 different entities are persisted and 10 different messages are sent to mb
    mb are able to load 10 different e from the database
    Everything works fine as long as there are 10 concurrent request. If there are 13 concurrent request, then one or two mb
    cannot load e from the database. It seems that the session bean has persisted the entities but some of them are still unload able from mb. They have been persisted , (I saw in the logs), but mb cannot load them.
    Initially I thought that a transaction mishap might be happening, so instead of persisting the entity and sending the message in one method in sb , I separated these two tasks in two methods a and b, in which both a and b uses RequiresNew transaction attribute. But the problem still remains. Please note if the number of parallel request are less than 10 then everything works fine. Is there something I am missing or is Jboss doing something buggy?
    The above situation is reproducible .
    Here is some more information about the problem along with some code snapshots. Note that the code is trimmed for clarity purposes.
    Request is a simple entity (e as mentioned in the problem before) that is persisted in session bean . Here is a trimmed snapshot
    Request.java
    package gov.fnal.ms.dm.entity;
    import java.io.Serializable;
    import javax.persistence.Column;
    import javax.persistence.Entity;
    @Entity
    @NamedQueries({@NamedQuery(name = "Request.findById", query = "SELECT r FROM Request r WHERE r.id = :id"),
    @NamedQuery(name = "Request.findAll", query = "SELECT r FROM Request r"),
    @Table(name = "cms_dbs_migration.Request")
    @SequenceGenerator(name="seq", sequenceName="cms_dbs_migration.SEQ_REQUEST")
    public class Request implements Serializable {
    private String detail;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO, generator="seq")
    @Column(nullable = false)
    private Long id;
    private String notify;
    .....The session bean is MSSessionEJBBean.
    MSSessionEJBBean.java
    @Stateless(name="MSSessionEJB")
    @WebService(endpointInterface = "gov.fnal.ms.dm.session.MSSessionEJBWS")
    public class MSSessionEJBBean implements MSSessionEJB, MSSessionEJBLocal, MSSessionEJBWS {
    @PersistenceContext(unitName="dm")
    private EntityManager em;
    .......    The methods that is called concurrently in this bean is
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public Request addRequest(String srcUrl, String dstUrl, String path,
    String dn, String withParents, String withForce, String notify) throws
    Exception {
    Request r = addRequestUnit(srcUrl, dstUrl, path, dn, withParents, withForce, notify);
    if (r != null) sendToQueue(r.getId());
    return r;
    }    It first adds the request entity and then sends a message to the queue in separate methods each using TransactionAttributeType.REQUIRES_NEW (I don't think this TransactionAttributeType is needed . I was just playing to see if this resolves the problem)
    Here is the method that actually persist the entity
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public Request addRequestUnit(String srcUrl, String dstUrl, String path,
    String dn, String withParents, String withForce, String notify) throws
    Exception {
    ....// Does something before persisting
    Request r = new Request();
    r.setNotify(notify);
    r.setPath(path);
    r.setPerson(p);
    r.setWithForce(withForce);
    r.setWithParents(withParents);
    r.setProgress(new Integer(0));
    r.setStatus("Queued");
    r.setDetail("Waiting to be Picked up");
    em.persist(r);
    System.out.println("Request Entity persisted");
    System.out.println("ID is " + r.getId());
    return r;
    }I can see that the log files has messages
    *{color:#800000}"Request Entity persisted" "ID is " 12 (or some other number){color}*
    . So it is safe to assume that the request entity is persisted properly before the message is sent to the queue. Here is how the message is sent to the queue
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    private void sendToQueue(long rId) throws Exception {
    QueueSession session = null;
    QueueConnection conn = null;
    try {
    conn = factory.createQueueConnection();
    session = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
    MapMessage mapMsg = session.createMapMessage();
    mapMsg.setLong("request", rId);
    session.createSender(queueRequest).send(mapMsg);
    } finally {
    if (session != null) session.close();
    if(conn != null) try {
    conn.close();
    }catch(Exception e) {e.printStackTrace();}
    System.out.println("Message sent to queue");
    }I can see the message
    {color:#800000}*"Message sent to queue"*{color}
    in the log file right after I see the
    *{color:#800000}
    "Request Entity persisted"{color}*
    message. So it correct to assume that the message is infact sent to the queue.
    Here is the md bean that gets the message from the queue and process it
    @MessageDriven(activationConfig =
    @ActivationConfigProperty(propertyName="destinationType",
    propertyValue="javax.jms.Queue"),
    @ActivationConfigProperty(propertyName="destination",
    propertyValue="queue/requestmdb")
    public class RequestMessageDrivenBean implements MessageListener {
    @EJB
    private MSSessionEJBLocal ejbObj;
    public void onMessage(Message message) {
    try{
    System.out.println("Message recived ");
    if(message instanceof MapMessage) {
    System.out.println("This is a instance of MapMessage");
    MapMessage mMsg = (MapMessage) message;
    long rId = mMsg.getLong("request");
    List<Request> rList = ejbObj.getRequestById(new Long(rId));
    System.out.println("rList size is " +  rList.size());
    for(Request r: rList) {
    //Does something and print something in logs
    System.out.println("Finsihed onMessage");
    }catch(Exception e) {
    System.out.println(e.getMessage());
    }    One thing to note here is that getRequestById is another method in the same session bean MSSessionEJB. Can that be the reason for not loading the request from the database when many concurrent request are present? Here is what it does
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public List<Request> getRequestById(Long id) throws Exception {
    System.out.println("Inside getRequestById id is " + id);
    return em.createNamedQuery("Request.findById")
    .setParameter("id", id)
    .getResultList();
    }    In the logs I do see
    {color:#800000}*"This is a instance of MapMessage"*{color}
    and I do see the correct Rid that was persisted before in the log
    *{color:#800000}
    "inside getRequestById id is 12"{color}*
    . Finally I do see
    *{color:#800000}
    "Finsihed onMessage"{color}*
    for all the request no matter how many are sent concurrently.
    *{color:#ff0000}Here is where the problem is . rList size is 1 for most of the cases but it returns 0 when the number of concurrent message exceeds 10.*
    *{color}*
    So you see there is no exception per se, just that entity does not get loaded from the database. I would like to mention this again, it does work properly when the number of concurrent request are less than 10. All the invocation of onMessage in MB are able to load the entity properly in that case. Its only when the number of concurrent request increases more than 10, the onMessage is unable to load the entity and the rList is 0.
    FYI I am using jboss-4.2.2.GA on RedHat enterprise linux 4 with jdk1.6.0_04
    Please let me know if there is more information required on this.
    Thank you

    Hello,
    I have seen a weird behavior of the MDB in Jboss or perhaps in transaction management.
    Here is a my scenario
    I have a session bean sb, an entity bean e and a message driven bean mb
    When a request comes to sb , it persists a new entity e and send a message (primary key) to mb
    mb then loads e from the database using one of the findByXX method and does something else.
    If 10 concurrent request comes to sb, 10 different entities are persisted and 10 different messages are sent to mb
    mb are able to load 10 different e from the database
    Everything works fine as long as there are 10 concurrent request. If there are 13 concurrent request, then one or two mb
    cannot load e from the database. It seems that the session bean has persisted the entities but some of them are still unload able from mb. They have been persisted , (I saw in the logs), but mb cannot load them.
    Initially I thought that a transaction mishap might be happening, so instead of persisting the entity and sending the message in one method in sb , I separated these two tasks in two methods a and b, in which both a and b uses RequiresNew transaction attribute. But the problem still remains. Please note if the number of parallel request are less than 10 then everything works fine. Is there something I am missing or is Jboss doing something buggy?
    The above situation is reproducible .
    Here is some more information about the problem along with some code snapshots. Note that the code is trimmed for clarity purposes.
    Request is a simple entity (e as mentioned in the problem before) that is persisted in session bean . Here is a trimmed snapshot
    Request.java
    package gov.fnal.ms.dm.entity;
    import java.io.Serializable;
    import javax.persistence.Column;
    import javax.persistence.Entity;
    @Entity
    @NamedQueries({@NamedQuery(name = "Request.findById", query = "SELECT r FROM Request r WHERE r.id = :id"),
    @NamedQuery(name = "Request.findAll", query = "SELECT r FROM Request r"),
    @Table(name = "cms_dbs_migration.Request")
    @SequenceGenerator(name="seq", sequenceName="cms_dbs_migration.SEQ_REQUEST")
    public class Request implements Serializable {
    private String detail;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO, generator="seq")
    @Column(nullable = false)
    private Long id;
    private String notify;
    .....The session bean is MSSessionEJBBean.
    MSSessionEJBBean.java
    @Stateless(name="MSSessionEJB")
    @WebService(endpointInterface = "gov.fnal.ms.dm.session.MSSessionEJBWS")
    public class MSSessionEJBBean implements MSSessionEJB, MSSessionEJBLocal, MSSessionEJBWS {
    @PersistenceContext(unitName="dm")
    private EntityManager em;
    .......    The methods that is called concurrently in this bean is
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public Request addRequest(String srcUrl, String dstUrl, String path,
    String dn, String withParents, String withForce, String notify) throws
    Exception {
    Request r = addRequestUnit(srcUrl, dstUrl, path, dn, withParents, withForce, notify);
    if (r != null) sendToQueue(r.getId());
    return r;
    }    It first adds the request entity and then sends a message to the queue in separate methods each using TransactionAttributeType.REQUIRES_NEW (I don't think this TransactionAttributeType is needed . I was just playing to see if this resolves the problem)
    Here is the method that actually persist the entity
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public Request addRequestUnit(String srcUrl, String dstUrl, String path,
    String dn, String withParents, String withForce, String notify) throws
    Exception {
    ....// Does something before persisting
    Request r = new Request();
    r.setNotify(notify);
    r.setPath(path);
    r.setPerson(p);
    r.setWithForce(withForce);
    r.setWithParents(withParents);
    r.setProgress(new Integer(0));
    r.setStatus("Queued");
    r.setDetail("Waiting to be Picked up");
    em.persist(r);
    System.out.println("Request Entity persisted");
    System.out.println("ID is " + r.getId());
    return r;
    }I can see that the log files has messages
    *{color:#800000}"Request Entity persisted" "ID is " 12 (or some other number){color}*
    . So it is safe to assume that the request entity is persisted properly before the message is sent to the queue. Here is how the message is sent to the queue
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    private void sendToQueue(long rId) throws Exception {
    QueueSession session = null;
    QueueConnection conn = null;
    try {
    conn = factory.createQueueConnection();
    session = conn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
    MapMessage mapMsg = session.createMapMessage();
    mapMsg.setLong("request", rId);
    session.createSender(queueRequest).send(mapMsg);
    } finally {
    if (session != null) session.close();
    if(conn != null) try {
    conn.close();
    }catch(Exception e) {e.printStackTrace();}
    System.out.println("Message sent to queue");
    }I can see the message
    {color:#800000}*"Message sent to queue"*{color}
    in the log file right after I see the
    *{color:#800000}
    "Request Entity persisted"{color}*
    message. So it correct to assume that the message is infact sent to the queue.
    Here is the md bean that gets the message from the queue and process it
    @MessageDriven(activationConfig =
    @ActivationConfigProperty(propertyName="destinationType",
    propertyValue="javax.jms.Queue"),
    @ActivationConfigProperty(propertyName="destination",
    propertyValue="queue/requestmdb")
    public class RequestMessageDrivenBean implements MessageListener {
    @EJB
    private MSSessionEJBLocal ejbObj;
    public void onMessage(Message message) {
    try{
    System.out.println("Message recived ");
    if(message instanceof MapMessage) {
    System.out.println("This is a instance of MapMessage");
    MapMessage mMsg = (MapMessage) message;
    long rId = mMsg.getLong("request");
    List<Request> rList = ejbObj.getRequestById(new Long(rId));
    System.out.println("rList size is " +  rList.size());
    for(Request r: rList) {
    //Does something and print something in logs
    System.out.println("Finsihed onMessage");
    }catch(Exception e) {
    System.out.println(e.getMessage());
    }    One thing to note here is that getRequestById is another method in the same session bean MSSessionEJB. Can that be the reason for not loading the request from the database when many concurrent request are present? Here is what it does
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public List<Request> getRequestById(Long id) throws Exception {
    System.out.println("Inside getRequestById id is " + id);
    return em.createNamedQuery("Request.findById")
    .setParameter("id", id)
    .getResultList();
    }    In the logs I do see
    {color:#800000}*"This is a instance of MapMessage"*{color}
    and I do see the correct Rid that was persisted before in the log
    *{color:#800000}
    "inside getRequestById id is 12"{color}*
    . Finally I do see
    *{color:#800000}
    "Finsihed onMessage"{color}*
    for all the request no matter how many are sent concurrently.
    *{color:#ff0000}Here is where the problem is . rList size is 1 for most of the cases but it returns 0 when the number of concurrent message exceeds 10.*
    *{color}*
    So you see there is no exception per se, just that entity does not get loaded from the database. I would like to mention this again, it does work properly when the number of concurrent request are less than 10. All the invocation of onMessage in MB are able to load the entity properly in that case. Its only when the number of concurrent request increases more than 10, the onMessage is unable to load the entity and the rList is 0.
    FYI I am using jboss-4.2.2.GA on RedHat enterprise linux 4 with jdk1.6.0_04
    Please let me know if there is more information required on this.
    Thank you

  • MDB topic listener and concurrent processing

    Hello to everybody.
    I ve prototyped simple db publisher ,which publishes changed data from database to JMS topic. Then I have my MDB which listens on JMS topic.
    I setup and implemented all correctly and it worked. There was 1 consumer = 1 mdb instance. Then I tried to do load testing , So I triggered 8000 changes from database. The db adapter did the job and published the 8000 messages on the JMS topic in a while. To mimic processing in MDB I put the sleep(10seconds) in MDB.
    MDB topic processing seems to me as not concurrent one. Why? I observed 10 message decrease with 5-10 seconds.
    What I expected was: concurrent processing of 8000 JMS messages by 1 MDB (so MDB is poolable component isnt it?).
    So for 500 instances of topic MDB and 8000 messages on the JMS topic, I expected at least 8000/500 X 10 = 160 seconds to process message load.
    I am using WLS 816.
    Can You give me some hits.
    Thanks
    Roman

    I did the same test on Weblogic 10 and it worked as expected. MDB durable subscriber consumed 8000 messages (each msg processing had 10 secs sleep inside.) within 2 minutes. So it is ok.
    But why it did not worked on WLS 8.1? Is this a bug ?

  • Concurrent users unable to open a shared Microsoft Access MDB database

    I have a share on a Cisco NSS2000, the NSS is in Workgroup mode (Firmware 1.13).
    Every user have read/write rights on this share.
    When I try to open an access MDB database from this share it happens that only a single user at time can open the database.
    The second user that try to open the database get a "Cannot lock file" error message.
    So, when a user has the Access DB opened, no-one other can open (or connect to) the same DB.
    It's impossible to open the DB using the access IDE ("Cannot lock file" error message).
    It's impossible to make multiple connection to the DB using OleDB ("Cannot lock file" error message).
    I've tried give full access to the mdb file.
    I've tried give full access to the mdb folder.
    I've even tried to give full access to the temporary LDB file.
    I always get the same error message.
    Is there a workaround?
    Thanks, Max

    I've finally been able to update the firmware to the latest 1.16.
    Now everything works fine, problem solved! :)
    Thanks,
    Max
    catung wrote:Max,Please update your firmware to the latest posted version, 1.16.Thanks-carl--Carl TungSBTG - PE, Storage
    From: IsiSviluppo <[email protected]>
    Reply-To: "[email protected]"
    <[email protected]>
    Date: Wed, 07 Apr 2010 00:07:20 -0600
    To: Carl Tung <[email protected]>
    Subject: Small Business Network Storage New message: "Concurrent users
    unable to open a shared Microsoft Access MDB database" YbIMb-16E-b7l
    catung,
    A new message was posted in the thread "Concurrent users unable to open a
    shared Microsoft Access MDB database":
    https://www.myciscocommunity.com/message/42739#42739
    Author  : IsiSviluppo
    Profile : https://www.myciscocommunity.com/people/IsiSviluppo
    Message:

  • AQ - MDB Concurrency issue

              Hi,
              I have written a java startup class to bind the AQ connection factory and AQ queue
              to the JNDI tree of a WebLogic server and have deployed an MDB on WebLogic to
              listen to the AQ.
              (I have used Eric Ma's code as an example.)
              The MDB is working fine and is continuously listening to the Oracle AQ hosted
              on a Solaris box.
              But, the problem is that no matter how many instances of the MDB are deployed
              in the pool, onMessage() method of just one MDB is called repeatedly i.e. only
              single instance of MDB consumes AQ messages no matter how many instance are in
              pool or how may threads are available in queue.
              The MDB is deployed on WebLogic server 7 sp 4 on a Win 2000 box and has 5 inctances
              in the pool. I am using OCI driver for the connection to the AQ. Oracle 9.2.0
              is on a Solaris box and the IP address and the machine name of the JMS client
              (i.e. windows machine) is included in the /etc/hosts of the Solaris box.
              Any help towards achieving concurrency in consumption of messages from Oracle
              AQ would be great.
              Regards,
              Diptanshu
              

              I don't think that would help. Coz that means that the message is consumed once
              by each of the consumers. That's not what I want. I wish to instance 2 of MDB
              to read remaining messages from AQ, when instance 1 is busy reading a message
              and processing it.
              One option is to use an MDB as a Façade and then just to post it to an internal
              queue (not AQ) to be picked up for other MDBs for further processing. But, then
              this creates a bottleneck in the form of a single listening point between the
              Façade & the AQ.
              Any better suggestions are welcome.
              Regards,
              Diptanshu
              "Eric Ma" <[email protected]> wrote:
              >
              >Does making AQ a multi-consumer queue help?
              >
              >Eric
              >
              >"Diptanshu Parui" <[email protected]> wrote:
              >>
              >>Hi,
              >>
              >>I have written a java startup class to bind the AQ connection factory
              >>and AQ queue
              >>to the JNDI tree of a WebLogic server and have deployed an MDB on WebLogic
              >>to
              >>listen to the AQ.
              >>(I have used Eric Ma's code as an example.)
              >>
              >>The MDB is working fine and is continuously listening to the Oracle
              >AQ
              >>hosted
              >>on a Solaris box.
              >>
              >>But, the problem is that no matter how many instances of the MDB are
              >>deployed
              >>in the pool, onMessage() method of just one MDB is called repeatedly
              >>i.e. only
              >>single instance of MDB consumes AQ messages no matter how many instance
              >>are in
              >>pool or how may threads are available in queue.
              >>
              >>The MDB is deployed on WebLogic server 7 sp 4 on a Win 2000 box and
              >has
              >>5 inctances
              >>in the pool. I am using OCI driver for the connection to the AQ. Oracle
              >>9.2.0
              >>is on a Solaris box and the IP address and the machine name of the JMS
              >>client
              >>(i.e. windows machine) is included in the /etc/hosts of the Solaris
              >box.
              >>
              >>Any help towards achieving concurrency in consumption of messages from
              >>Oracle
              >>AQ would be great.
              >>
              >>Regards,
              >>Diptanshu
              >
              

  • MDB Maximum concurrent beans for Weblogic on Linux

    Has anyone noticed that the formula for determining maximum concurrent beans in use for MDBs for WL/Linux platform does not work. However, it does work for WL/Windows. The number of bean in use keeps growing (not bounded by either the number of worker threads or <max-beans-in-free-pool> settings. I have noticed the number crossing 1000 when <max-beans-in-free-pool> is set to only 40 and ThreadCount on the default execute Queue is only 100.

    if your MDB is using the default Execute Queue with 100 threads, the max instances of the mdb should be 51.
    I am surprised that this should be different on Win and Linux.
    Are your beans getting destroyed due to exceptions being thrown from the onMessage method ? this would be reflected in the DestroyedBeansCount.
    which version are you using ?
    cheers,
    Mihir

  • Urgent - MDB Concurrent Msg Pickup Issue

    hi all
    i am using weblogic 81 sp2 , websphere 5.2 as a foreign server. for Concurrent message processing ,
    my MDB not able to pick up message at right time.
    if client put 25 msg at time in my request queue, my MDB pick-up first 8 msg only at a time,after that MDB waiting for these msg processing.
    after these msg processing then MDB pick up other 8 msg.... so i cant perform well.
    how to make it my MDB pick up all message at a right time.
    and one more thing
    if i declare user defined execute thread and assign my MDB with execute thread (using <dispatch-policy>),i got jms exception.(JMS exception:MQJMS2005: failed to create MQQueueManager for 'localhost:UTSD11')
    (i got BEA-014005 warning)
    is it possible to assign user-define execute thread?
    plz clear my problem
    thanx n advance
    regards
    muruganandam

    Hi,
    Your MDB is processing as many messages at a time it has been configured for. So, you should increase your concurrency level from 8 to whatever level you think is acceptable for your application.
    Hope this helps,
    Arnaud
    www.arjuna.com

  • MDB Topic & concurrency

    The JMS faq say
    "For Topics in WebLogic JMS 6.1, there is one JMSSession per bean instance in
    the pool. Because of the way Topics work, the session, and thus every bean instance,
    receives a copy of each message published on that Topic.
    -- snip --
    For each kind of MDB listening on the topic, the message is delivered exactly
    once (i.e., the message will be delivered exactly once to an instance in each
    named MDB pool listening on the topic)."
    The two statements seem to condradict each other. One seems to say that each
    instance in a pool will get a copy of the message and the otehr syas that the
    pool as a whole will get only one copy of the message.
    Am I being dense? Is there a version issue? What's going on?
    -Gordon

    If you have a cluster of N WLS servers and on each server you have a MDB
    deployed which listens to topic T. Then an instance on each of the N
    servers will receive a message from the topic.
    If you send P messages to the topic T, then up to P instances may be
    processing the messages in parallel on a given server. However, under
    the covers they will all actually be using the same JMS Session. The
    EJB container does some "fancy" stuff to get the JMS acks right. This
    is one of those things that makes MDBs very attractive since it's a pain
    to write this code yourself in JMS.
    -- Rob
    Gordon Palumbo wrote:
    I would agree, but given the FAQ and this statement from an old post
    (feb 2001)
    "In the upcoming 6.0 service pack, only one instance per deployment
    will receive
    a copy of a topic message. In 6.0, each deployment listener instance
    receives
    a copy."
    The statement that each instance get's a session (and is thus a
    seperate listener)bothered
    me.
    I got worried about expected behavior or a lingering bug in Weblogic 6.X
    I was looking for someone to confirm the actual behavior in WebLogic 6.1
    -Gordon
    Simon Evans wrote:
    it is saying for each bean, there is a pool of instances. the message
    gets delivered to each bean, but to only one instance from the pool.
    one instance will be picked out of the pool to handle the message.
    it would not make sense for each instance of the bean in a pool to
    receive the message.
    Gordon Palumbo wrote:
    The JMS faq say
    "For Topics in WebLogic JMS 6.1, there is one JMSSession per bean
    instance
    in
    the pool. Because of the way Topics work, the session, and thus everybean instance,
    receives a copy of each message published on that Topic.
    -- snip --
    For each kind of MDB listening on the topic, the message is deliveredexactly
    once (i.e., the message will be delivered exactly once to an instancein each
    named MDB pool listening on the topic)."
    The two statements seem to condradict each other. One seems to saythat each
    instance in a pool will get a copy of the message and the otehr syasthat the
    pool as a whole will get only one copy of the message.
    Am I being dense? Is there a version issue? What's going on?
    -Gordon

  • Access Database (.mdb) on Windows Server 2012 R2 Essentials

    Hi guys, thanks for your time!
    SCENARIO:
    - Windows Server 2012 R2 Essentials
    - Windows 7 Ultimate Clients (3 clients)
    - VB6 application on clients using a MS Database (.mdb) hosted on the server.  
    - Clients access the database (.mdb) via a mapped network drive (K:).
    PROBLEM:
    - Microsoft Database (.mdb) on server gets corrupted frequently.
    - Clients don't "flush their changes" back to the database: database was not updated.
    WORKAROUND:
    - Database was moved from the server to one of the Windows 7 clients.
    - Application is running OK.
    CONFIGURATION:
    - Permissions are correct: network and NTFS.
    - No faulty network hardware: switch, cabling, NICs.
    - Computers and Server hardware is new.
    - UPS are used everywhere.
    SOME LINKS:
    SMB 3.0 
    - Opportunistic Locking and Read Caching on Microsoft Windows Networks.
    - Windows 7 cannot
    open the shared MS Access database if it's opened by another user
    - Initializing the
    Microsoft Jet 4.0 Database Engine Driver
    - Moved to
    Server 2012 getting Access Database Corruption
    Oplocks
    - Configuring
    opportunistic locking in Windows
    - Understanding
    offline files
    - How to
    enable and disable SMBv1, SMBv2, and SMBv3
    - Is it possible to
    monitor and log actual queries against an Access MDB?
    Now, server is useless if it is not hosting our database. Any ideas, please? Do I need to diagnose using Wireshark? Or using Sysinternals Process Monitor? I think that is a waste of time. 
    Thank you! 

    Thanks for your reply.
    Software is from a 3rd party provider. It currently supports concurrency. It was deployed on Windows XP. SQL Server would be a nice upgrade, however that is
    not an option.
    Something has changed with newer versions of Windows. That is what I am going to study in a lab I prepared with a real server and some clients.
    File-sharing databases (Microsoft JET databases) are very old technology even before I was a college student. However, I have been very busy researching this technology.
    It was made for multi-user environments. It is highly tied to file sharing services from Windows: SMB protocol.
    Windows XP, Vista, 7 and 8 use different versions of this protocol. I think that is the root of the problem. With old technology, application was running fine.
    With new technology, application is troublesome. I will check several things: JET drivers vs. ACE drivers, SMB tweaks, etc.
    UPDATE:
    Basically, there are 4 general answers to this issue:
    1) Migrate your Access Database to SQL Server Express (or another RDBMS engine).
    2) @Server: disable SMB 2.0/3.0 protocol stack by powershell command. Network speed decreases.
    3) @Clients: disable client redirector caches by using regedit.
    4) @Server: disable the leasing on the file server. 
    5) @Server: tuning Broadcom NIC parameters.
    References:
    - https://technet.microsoft.com/en-us/library/ff686200(WS.10).aspx
    - https://msdn.microsoft.com/en-us/library/windows/desktop/aa365433(v=vs.85).aspx
    - http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Q_28482197.html
    - http://tipsntricks.sherr.co.uk/stop-smb-corrupting-files/
    - http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
    - https://social.technet.microsoft.com/forums/windowsserver/en-US/67baa9fd-5eaf-438e-9cc4-dc1a531b9e19/disabling-oplocksmb2-vs-fileinfocachelifetime
    - https://social.technet.microsoft.com/Forums/windowsserver/en-US/7336d31b-6c24-468a-9c47-750244ae3a8c/moved-to-server-2012-getting-access-database-corruption
    - https://social.technet.microsoft.com/Forums/en-US/e9567167-22db-4b8c-9f96-a08b97d507f9/server-2012-r2-file-server-stops-responding-to-smb-connections
    - http://support2.microsoft.com/kb/2957623
    - http://support2.microsoft.com/kb/2899011
    - http://support2.microsoft.com/kb/2955164
    - https://social.technet.microsoft.com/Forums/en-US/7bd0aa5b-eb95-40a8-a56d-c6013273665c/extremely-slow-smb-network-speed-server-2012-r2?forum=winserver8gen

  • MDB behavior with Foreign JMS Provider

              I am experiencing some MDB behavior which I do not quite understand. I would appreciate
              if someone could tell me what might be happening.
              An application on WebLogic 8.1 SP1 (also tried it with SP2) has MDB's which listen
              on a MQ Queue. If I put a large XML message on the MQ Queue (say around 600 KB),
              the onMessage execution is very random, For the large messages only 1 MDB gets
              invoked and the other messages just sit on the MQ Queue. Even though I have defined
              an weblogic execute queue for the MDB's and they have 15 threads allocated.
              The other messages get picked up after the first one gets completed. The problem
              is the whole transaction (which is XA) can take a while (upto 10 minutes). This
              is not intended, but for some reason it takes that long.
              Also, while monitoring the MDB execute queues, I noticed that none of the threads
              from that queue are performing the work and a thread dump shows that the weblogic.ejb20.internal.JMSPoller
              thread has invoked the MDB and is currently waiting for the database to finish
              some processing.
              When the message size is smaller, the MDB's fire concurrently and are executed
              on the MDB execute queue.
              Thanks,
              Ketan.
              

    When we're using MDBs against a foreign JMS provider with XA, the EJB
              container tries to reduce the number of threads that are blocked waiting for
              a message. You should see lots of threads working when there are lots of
              messages on the queue, a few threads (or only one) working when the queue is
              empty or nearly so, and there should be some ramp-up and ramp-down time in
              between. It sounds like the ramp-up takes longer in your case because
              receiving the very first message takes a long time.
              If this behavior is causing big problems for you, you might want to contact
              product support and file an enhancement request.
              greg
              "Ketan" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Here is some more information regarding this issue.
              >
              > When I place sufficiently large messages (such that the parsing and
              processing
              > of these messages takes longer than it does for normal size messages), I
              notice
              > the following behavior.
              >
              > Lets say I put 6 large messages on the MQ Queue. The server immediately
              picks
              > up 1 message and starts processing it. The other 5 messages are sitting on
              the
              > MQ Queue, while the MDB execute queue has all 15 idle threads.
              >
              > After the processing of the message is done, 2 messages get picked up.
              This time,
              > 1 thread in the MDB execute queue gets the message and the other is
              processed
              > by the JMSPoller thread. After these 2 messages are processed, 3 Messages
              get
              > picked up and this time 2 messages are on the MDB execute queue and 1 is
              processed
              > by the JMSPoller.
              >
              > So based on this the question is ..Is this the expected behavior? I was
              under
              > the impression that the poller would simply dispatch messages to the
              execute queue,
              > and as a result, I was expecting all the messages would get picked up from
              the
              > MQ queue pretty fast and would not have to wait for 1 or more MDB's to
              finish
              > processing.
              >
              > I would really appreciate any suggestions anyone may have for me.
              >
              > Again the environment is WLS 8.1 SP2, MQ 5.3
              >
              > thanks,
              > Ketan
              

  • MDB - Restricting to one bean at a time

    I have an application that sends out a bunch of messages to a JMS queue. I need an MDB (Message Driven Bean) to act on the message - but in a serial fashion - i.e. only one message should be processed at a time - the rest of the messages remain in the JMS queue until the processing of the current message is complete - i.e. multiple MDB should not be spawned concurrently to process multiple messages to the queue.
    I need to do this because my task is resource intensive and need MDB because my process needs to be asynchronous.
    I can't process more than one message at a time concurrently due to resource issues.
    Any ideas/tricks to get this to work. Appreciate any input you may have.
    Thanks!

    You just declare you MDB to have a single instance in the pool. I beleieve this is specified in the app server descriptor for the MDB.

Maybe you are looking for