You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by um <um...@mib.com> on 2013/11/07 13:40:47 UTC
problem when using websphere MQ under heavy load
I have a simple MDB deployed on tomEE that is reading from a websphere MQ
queue. Now the behavior seems fine under low load, but under heavy load I
get some failures. I opened a service request with IBM and after reading the
manual, this is was their response -
Hi L2,
Since the TM software is calling MQ's xa_start function trying to
introduce an XID that has already been used in the past, MQ is correct
to reject this. The investigation into why duplicate XIDs are being
used by the TM must be performed by the owners of the TM.
.
MQ's record keeping is completely proven over approx. 16 years where
this function has been present in the product, and extensively used
on many many customer installations. I therefore don't think it is
plausible that MQ has mis-identified a duplicate. Is this what the TM
vendor claims? Please let us get a clear statement on that point.
.
At MQ 7.5 you can get a complete (and verbose!) listing of all
transactions currently-known to the queue manager, using the dspmqtrn
utility. Specify -a or -q options. See the info center for more.
.
Is the TM software "TomEE" one of the ones we claim to work with? A
quick check in the "Transaction Manager" section under the "Windows"
tab on this page
.
http://www.ibm.com/support/docview.wss?uid=swg27027462
.
suggests it is not a supported environment for XA.
.
Regards,
Martin (MQ L3) MQNov13MG
The MQGET failing with MQ_SYNCPOINT_NOT_AVAILABLEis a result of the
duplicate XID error. I think we initially thought they were but then I
saw different TIDs and thought they might be different issues.
I believe Tony touched on this in his update on pg 19.
.
Just to clarify there are 2 xa_starts with the same
globalId.
1)For thread '41'.
13:19:52.728.4Z 0041 @1fca6d5 c.i.m.j.remote.api.RemoteFAP
--- { xa_start(Hconn,Xid,int,int) [com.ibm.mq.jmqi.remote.impl.
RemoteSession[connectionId=414D5143514D5F4A415942495341575421B16F52201D9
E01]]
[[Xid:globalId=3a000000047544d494400000000000000000000000000000000000000
0000000000000,length
=64,branchId=1000000047544d494400000000000000000000000000000000000000000
0000000000,length=64]] [2] [0]
...............
2)
09:10:03.710.CL 0045 @8c3392 c.i.m.j.remote.api.RemoteFAP
--- { xa_start(Hconn,Xid,int,int) [com.ibm.mq.jmqi.remote.impl.
RemoteSession[connectionId=414D5143514D5F4A4159424953415754F5EC73522000E
B01]]
[[Xid:globalId=3a000000047544d494400000000000000000000000000000000000000
0000000000000,length
=64,branchId=1000000047544d494400000000000000000000000000000000000000000
0000000000,length=64]] [7] [0]
................
This results in the XAER_DUPID message (-8).
.
And then the MQGET failing.
As L3 mentioned in their previous update (please review) tomEE and the
MQ RA have not been tested. At this point you really need to
engage tomEE support (as the TM) to determine why they are using the
XID for 2 different xa_starts.
------------------
Can tomEE support help us out with this?
Thanks
--
View this message in context: http://openejb.979440.n4.nabble.com/problem-when-using-websphere-MQ-under-heavy-load-tp4666037.html
Sent from the OpenEJB User mailing list archive at Nabble.com.