MDB's onMessage not invoked till the previous call completes

[Former Member]

We have a J2EE application deployed in NW 04S. The application has a MDB (lets call it MyMDB) configured to listen to a Queue (lets call this MyQueue). As part of our application, we send messages to MyQueue and the MyMDB listening on this queue starts processing through the onMessage method. Here's a pseudo-code of the onMessage method:

onMessage(Message msg)  {
 
 //do some processing. call some utility etc...
 //this processing is going to take time
 utility.doSomeOp();
 
}

The message is sent through a client in a non-transacted and AUTO_ACKNOWLEDGE Session as follows:

session = theConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

We are observing a weird behaviour that if multiple messages are sent to the MyQueue in succession, the second onMessage invocation on MyMDB happens ONLY AFTER the first onMessage call has completed (which can takes minutes and sometimes even hours).

Is there something i am missing here (maybe in configurations)? I would have expected that the onMessage method will be called as soon as the messages are available, irrespective of whether the previous message's onMessage method is in-progress or not.

BTW, what does a Container Size (available on the Visual Admin) for a MDB signify? Currently its set to the default 0. Any change that needs to be done to this value?

We also obtained the Thread Dumps and even checked the NW DB for the BC_JMSQUEUE table. Please let me know, if anyone would like me to post it here, for figuring out what the issue is.

Thank you.

-Jaikiran

[Former Member]

Any inputs?

[Former Member]

Hi

have a look at the <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/604e2b64-e689-2910-64b3-ffd650f83756">JMS faq</a> question 53 should solve the problem.

The troubleshooting guide you have found is for the case no message at all comes. You have a slightly different problem - messages are coming one by one.

HTH

Peter

[Former Member]

Peter,

You got it right !

The < parallel-consumers> is what we are looking for. The JMS faq mentions that it is part of NW 04 SP19 version. We are using NW 04s SP11. We have been in touch with the NW support and as per them this property is supported in NW 04s starting SP11. However, a bit of testing with our application shows that this property does not work as expected. Apparently there are some other optimizations which the NW server does because of which this property is getting ignored. We have set this property to a value of 8, however, unless there are more than 100 messages waiting in the queue, the message processing still happens in sequence. And when there are 100 messages in the queue, the processing happens 2 messages at a time.

We are trying to figure out what additional optimization is being done by NW (based on what properties?) which leads to this behaviour. If you have any pointers about why this might be happening, please do let us know. It would be of great help.

In any case, you have been of great help by pointing us to the JMS FAQ. Thanks a lot.

[Former Member]

A little bit of googling led me to this:

http://help.sap.com/saphelp_nw70/helpdata/en/44/03edd58d4e2d2fe10000000a11466f/frameset.htm

which says:

[code]Messages may not come to MDB that uses transaction but takes the connection from non-XA connection factory

Problem appears when non-XA factory is used with MDB. To analyze the problem, perform a thread dump, there should be a thread that has the following line in the stack trace:

at com.sap.jms.client.session.Session.waitCommit(Session.java:2630)

Solution

Usage of XA factories

jmsfactory/default/XATopicConnectionFactory or jmsfactory/default/XAQueueConnectionFactory in the deployment descriptor and redeploying the application will solve the problem.

[/code]

We took a thread dump and found the following:

[code]"SAPEngine_Application_Thread[impl:3]_4" prio=5 tid=0x00000000070965d0 nid=0x1684 in Object.wait() [0x00000000097de000..0x00000000097dfb80]

at java.lang.Object.wait(Native Method)

- waiting on <0x0000000023d1d3f0> (a java.lang.Object)

at java.lang.Object.wait(Object.java:429)

<b>at com.sap.jms.client.session.Session.waitCommit(Session.java:2609)

- locked <0x0000000023d1d3f0> (a java.lang.Object)</b>

at com.sap.jms.client.connection.ConnectionConsumer$ConsumerListener.onMessage(ConnectionConsumer.java:139)

at com.sap.jms.client.session.Session.run(Session.java:641)

at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)

at java.security.AccessController.doPrivileged(Native Method)

at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:100)

at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:170)

[/code]

This thread dump does show that the at com.sap.jms.client.session.Session.waitCommit(Session.java:2609) condition. However, the connection factory that we are using is configured to use XAQueueConnectionFactory (through the Visual Admin).

Any inputs highly appreciated.