| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS, MQETC and Backout Messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Fri Jun 05, 2009 9:39 am Post subject: JMS, MQETC and Backout Messages |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQ Extended Transactional Client version 6.0.2.4.
Installed on a RHEL 4 client server.
The version of Weblogic is 10.0MP1.
The Queue Manager is running on a seperate server. The MQ Server is RHEL 4, MQ 6.0.2.6.
We are trying to understand how/when/why the MQETC commits a message to the backout queue. It looks like once the MQ messages backout count meets the threshold defined on the MQ queue's Backout Count property, the MQETC does put it to the queue specified in the Backout Queue property of the original app queue. BUT, it appears to do it under syncpoint, and it stays uncomitted until the app process a subsequent good message. It appears that it is only then that the commits occur, and finally the backout message appears. Is this normal?
This is the only thing I could find about when the backout commit is supposed to occur, but it's not clear to me.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaw.doc/uj25590_.htm
"If the application server supplies an XASession, messages are committed or backed out depending on a distributed transaction. The application server takes responsibility for completing the transaction."
I asked the app app person I am working with to see if you could just issue a commit in his transaction after a backout occured. His response was:
| Quote: |
To answer you last question, there are two things which would prevent me to issue an extra commit. One is the fact that I am running under a J2EE Container Managed Transaction with very little transactional control and the other is the fact that the vendor actuallly owns the Message Driven Bean code and I am not able to modify it.
|
He further stated:
| Quote: |
| My conjecture is that this is a behavior in the IBM MQ JMS client (or its resource manager) and not with the transaction manager, which in this case is Weblogic. The reason why I believe this is because in a different test I eliminated MQ from the picture and used a different messaging system which provided similar re-queuing capabilities. Under a distributed transaction I was seeing the message show immediately in the "back out" queue. The other point is that in the provided trace the XA Transaction Manager is trying to commit the message on the backout queue but IBM is not allowing it. |
So, anyone know what the what/when/why/how is related to MQETC and commiting backout messages? I did open a PMR, but they are asking me to run MQ server traces, MQ client traces, WebLogic traces, MQ QM error logs, etc, as if they want to reverse engineer what is happening to answer the question! 
I sent the developer this link so he may be along in a moment to provide more detail if needed.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Wed Sep 24, 2014 7:56 am; edited 1 time in total |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Jun 05, 2009 9:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 09, 2009 7:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Here are the results of the PMR:
A Transactional MDB is trying to read a message. The retry count is reached and the message is transactionally put to the backout queue.
As the MDB is transactional, this backout is not committed. There are no XA_COMMIT calls being issued, so commit is never called by the MDB, and so any messages that have been requeued to the backout queue are eventually being rolled back. The design on the WMQ side of things is that XA COMMIT cannot be called on the message that was sent to the backout queue, but there will be a good message along in the near future and when an XA_COMMIT is issued all the requeued messages will also be committed.
The transaction will last until a commit is issued, you will only need one good message that is committed to commit all the bad messages that were requeued , so if you have a run of 14 bad messages that were requeued, then one good message that was committed, then all 14 requeues will be committed.
The BEA WLS implementation of the MDB uses a WMQ consumer to actually read the messages, and the backout logic is carried out by this consumer in this case. When it consuming the message it checks the retry count, and if it is too high the consumer actually requeues the message. There are two scenarios that WMQ needs to consider when dealing with this issue, and to be honest they contradict each other. We can give "right away" committing of backed out messages, but not including the requeue in the MDB transaction, but this opens a window in which it is possible to lose messages. We believed that delaying the commit was a fair side effect of not losing any customer data (or duplicating is the other possibility).
There is no right thing to do in this scenario, we believed that most of our customers have a fairly busy production system with a steady flow of messages and therefore this delay in committing should not be a problem. To repeat, the downside to "right away" is that you have that window where any failure would result in you either having duplicate message or loosing the data, your message rate would have to be exceptionally low for this to cause you any real problems in production (msgs/day instead of msgs/sec or msgs/min)."
The information is presently not documented on infocenter. It is documented internally and we are looking to see if it can be added as a technote soon.
The behavior is same with WMQ V7 or V6.
If the messages are part of a unit of work and a message is moved to the backout queue and then we have a major problem due to which the transaction can not be committed then the message would indeed be rolled back to the original queue. The entire process of getting the message from the original queue, backing it out to backout queue and rolling back the message to original queue ( as part of rollback ) will increase the backout count by 1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue Jun 09, 2009 11:39 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Wow... thats really interesting. I've never used Weblogic (just WAS) and so have never seen this behaviour before.
I've read the text a few times now and wonder if the Weblogic server was to issue an XA_COMMIT after detecting the message backout then all would be well? Maybe i'm misreading it after a long day but its just my thoughts.
I have seen some batch processing scenarios where message processing may occur once a day so this scenario could pose an issue there.... |
|
| 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
|
|
|
|
