|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Webspshere MQ 7.0 JCA Adapter Transaction Rollback Issue |
« View previous topic :: View next topic » |
Author |
Message
|
Ravisankar_Challa |
Posted: Thu Nov 18, 2010 6:35 am Post subject: Webspshere MQ 7.0 JCA Adapter Transaction Rollback Issue |
|
|
Newbie
Joined: 18 Nov 2010 Posts: 3
|
I developed a MDB3.0 using the JCA adapter that comes with MQ 7 which runs in Jboss App Server 5.0.2.
I am using Container Manged Transaction & Transaction Required.
5 messages are sent to MDB for testing.
let us consider the messages sent are
Message 1
Message 2
Message 3
Message 4
Message 5
Here is my code.
package com.example;
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.MessageDrivenContext;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
import org.jboss.ejb3.annotation.Pool;
import org.jboss.ejb3.annotation.ResourceAdapter;
@MessageDriven(
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "maxPoolDepth", propertyValue = "1"),
@ActivationConfigProperty(propertyName = "maxMessages", propertyValue = "1"),
@ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "true"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "WMQ.INPUT.Q"),
@ActivationConfigProperty(propertyName = "readAheadAllowed", propertyValue = "DISABLED"),
@ActivationConfigProperty(propertyName = "messagingType", propertyValue = "javax.jms.MessageListener"),
})
@TransactionManagement(TransactionManagementType.CONTAINER)
@Pool(value="StrictMaxPool", maxSize=1, timeout=10000)
@ResourceAdapter(value="wmq.jmsra.rar")
public class Test implements MessageListener {
public Test() {
// TODO Auto-generated constructor stub
}
@Resource
MessageDrivenContext context;
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void onMessage(Message message) {
try {
System.out.println(((TextMessage)message).getText());
} catch (JMSException e) {
e.printStackTrace();
}
try {
throw new Exception("Exception");
} catch (Exception e) {
context.setRollbackOnly();
}
}
}
Output is:
Message 1
throw new Exception("Exception")
Message 2
throw new Exception("Exception")
Message 1
throw new Exception("Exception")
Message 2
throw new Exception("Exception")
Message 1
throw new Exception("Exception")
Message 2
throw new Exception("Exception")
....
ideally the output should always be message 1 if transaction rollback is proper..
I am expecting output to be
Message 1
throw new Exception("Exception")
Message 1
throw new Exception("Exception")
Message 1
throw new Exception("Exception")
Message 1
throw new Exception("Exception")
Is this a bug or am i missing something? |
|
Back to top |
|
 |
Ravisankar_Challa |
Posted: Fri Nov 19, 2010 7:05 pm Post subject: |
|
|
Newbie
Joined: 18 Nov 2010 Posts: 3
|
The MQ resource adapter version is
<resourceadapter-version>7.0.1.3-k701-103-100812</resourceadapter-version>
After analyzing for a long time i figured out something.
Initially when i deployed MDB consumer count on the queue is 1 (IPPROCS= 1). but when i send messages (IPPROCS is becoming 2). After some time it is coming back again to 1.
i set the following properties in mq resource adapter ra.xml
maxConnections = 1
connectionConcurrency = 1
Also in MDB
@ActivationConfigProperty(propertyName = "maxPoolDepth", propertyValue = "1"),
@ActivationConfigProperty(propertyName = "maxMessages", propertyValue = "1"),
@ActivationConfigProperty(propertyName = "readAheadAllowed", propertyValue = "DISABLED"),
to make (IPPROCS= 1) always.
still the consumer count is increased to two, my ultimate goal is to set a single consumer on queue. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Nov 19, 2010 7:48 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
IPPROCs is not the same thing as consumer threads, particularly with JMS listeners. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Nov 19, 2010 8:24 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mqjeff wrote: |
IPPROCs is not the same thing as consumer threads, particularly with JMS listeners. |
@ravisankar: FYI with MDBs the max IPPROCS (if only the MDB is listening) is max number of MDB instances +1. So seeing an ipprocs of 2 for a single instance of MDB is not something to worry about. Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Ravisankar_Challa |
Posted: Sat Nov 20, 2010 1:44 am Post subject: |
|
|
Newbie
Joined: 18 Nov 2010 Posts: 3
|
Thanks for the response. it made me clear now.
Now there is only one consumer, in this case if a transaction rollback happens after reading a message from the queue.
Ideally what should happen ?
Message will be put back to the top of the queue & the same message is consumed again. Is this correct?
In my case what i observed is if a transaction rollback occurs next message in the queue is consumed and the current message is put back on the top of the queue.
So the out of the mdb is
Message 1.
rollback
Message 2.
rollback.
Message 1.
rollback
Message 2.
rollback.
is this an expected behavior ?
Kindly help me is there any setting i need to change in the MQ resource adapter . |
|
Back to top |
|
 |
Vitor |
Posted: Sat Nov 20, 2010 4:56 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Ravisankar_Challa wrote: |
is this an expected behavior ? |
Unexpected but unsurprising. WMQ doesn't guarantee delivery sequence unless you request it at message put time by using grouping, and require such sequencing generally is called "message affinity" and is not best practice. A search of this forum will yield a wealth of discussion on this.
So you shouldn't rely on pure FIFO message delivery. I would imagine that message 2 has already been tagged as being the top of the queue when message 1 is read off (so that if a 2nd application does a get it received message 2). Clearly this pointer is not being moved when the rollback happens but shortly thereafter so the next get doesn't get the rollback message.
I'd welcome other theories (especially from those who know) but you shouldn't rely on getting the rolled back message on the next read.
(You should bear in mind that whichever message you get will be identified as rolled back correctly). _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Nov 20, 2010 6:49 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
I believe this is expected behavior. If you check the specs there is a "reprocess interval" during which a rolled back message waits before getting processed again.
There is also a poll interval... What happens is that the system sets up a browse session that will feed it's content to the "onMessage" method of the MDB. This gets refreshed at poll interval, or if empty whenever a message hits the queue. Also the rollback will take some time. While it processes the next message is already being made available...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|