| Summary: | JMS/MDB TCK does not pass due to issues with sending test messages | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Jiri Pechanec <jpechane> | ||||||
| Component: | qpid-jca | Assignee: | Weston M. Price <wprice> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | MRG Quality Engineering <mrgqe-bugs> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 2.0 | CC: | astitcher, cdewolf, gsim, jneedle, mvecera, tross, wprice | ||||||
| Target Milestone: | 2.0.4 | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-09-22 12:45:25 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | 738316 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jiri Pechanec
2011-09-13 10:25:44 UTC
Created attachment 522886 [details]
Logs and sources
Good analysis. ConnectionFactory definition looks fine as well.
Since this is on the broker side, Gordon would probably be better able to help with this. However, a few thoughts.
It is strange, as you observed, that in the case of the TCK/MDB test, no transaction seems to be started, even though the ejb descriptors clearly specify that they are required.
The cases that a Broker will drop messages are:
1) If the destination or exchange doesn't exist
2) If the key/subject doesn't match any binding on the exchange
3) If the queue is full
The one thing we might want to do is deploy everything and then run qpid-stat -q to make sure the destinations that the test expects to be there are actually being created correctly. But again, I agree that no transaction appears to have been started.
The only thing I can think of is in the first case (MDB/TCK), there is only one resource and the transaction manager is optimizing the test to use local transactions. JBossTM will do this in the case that there is only one resource enlisted in the transaction as the two phase commit protocol would be unnecessary overhead.
Are you running your test in the same instance as the TCK? There is a setting in the jbossts-properties.xml file that toggles the JBossTM to use two phase commit even in the case of one resource. The property is
<property
name="com.arjuna.ats.arjuna.coordinator.commitOnePhase" value="YES"/>
A 'YES' value will tell the JBossTM to commit the one phase resource without the 2PC protocol. A 'NO' value will disable this and force the use of 2PC even in the case that there is only one resource.
If you are testing recovery and using the file from the jca-xa-recovery project you may have this value set to NO. Can you verify this for me? That's the only thing I can think of at this point.
Hi,
unfortunately messages were not dropped (at least officially). I asked one guy from MRG QE for a help and we identified that any condition for dropping was not satisfied and even the drop counter displays zero
Exchanges
exchange type dur bind msgIn msgOut msgDrop byteIn byteOut byteDrop
============================================================================================
amq.direct direct Y 3 1.34k 1.34k 0 178k 178k 0
amq.topic topic Y 1.48k 1.48k 1.11m 151 25.9k 20.4m 3.39k
qmf.default.direct direct 3 217 217 0 13.4m 13.4m 0
amq.fanout fanout Y 0 0 0 0 0 0 0
amq.match headers Y 0 0 0 0 0 0 0
qmf.default.topic topic 3 154k 70 154k 537m 15.0k 537m
qpid.management topic 6 126k 0 126k 142m 0 142m
direct 1.52k 53.6k 53.6k 0 1.92m 1.92m 0
Bindings
[jpechane@mrg01 ~]$ qpid-config queues -b |grep jms_ee_mdb_mdb_sndQ_MDB_QUEUE -A 10
Queue 'jms_ee_mdb_mdb_sndQ_MDB_QUEUE'
bind [jms_ee_mdb_mdb_sndQ_MDB_QUEUE] => ''
Queue 'jms_ee_mdb_mdb_sndToQueue_MDB_QUEUE'
bind [jms_ee_mdb_mdb_sndToQueue_MDB_QUEUE] => ''
Queue 'jms_ee_mdb_mdb_synchrec_MDB_QUEUE'
bind [jms_ee_mdb_mdb_synchrec_MDB_QUEUE] => ''
Queue 'jms_ee_mdb_xa_MDB_QUEUE_BMT'
bind [jms_ee_mdb_xa_MDB_QUEUE_BMT] => ''
Queue 'jms_ee_mdb_xa_MDB_QUEUE_CMT'
bind [jms_ee_mdb_xa_MDB_QUEUE_CMT] => ''
Queue 'mrg_mrg_jca_mdb_transactions_in'
bind [mrg_mrg_jca_mdb_transactions_in] => ''
[jpechane@mrg01 ~]$
The com.arjuna.ats.arjuna.coordinator.commitOnePhase optimization was enabled, so I turned it off and re-run the tests. Unfortunately with the same results
Cool. Thanks for doing both. I am going to loop Gordon in as this one is on the broker side at this point. First broker trace in the description shows a local transaction enabled (TxSelect) but no commit. Hence when the session is detached, the transaction is aborted and the message sent under it is discarded. I believe I see the issue. In QpidRALocalTransaction, on a commit we evaluate:
try
{
if (_mc.getSession() != null && _mc.getSession().getTransacted())
{
_mc.getSession().commit();
}
}
catch (JMSException e)
{
throw new ResourceException("Could not commit LocalTransaction", e);
}
finally
{
_mc.unlock();
}
Obviously, in JCA the getTransacted() flag is going to return false, more to the point, we shouldn't really be using this flag at all to evaluate whether or not we should commit.
Good catch. I will file a bug and link this one to the other as a dependency.
Created attachment 523844 [details]
Logs with build from Sep 19th
I tried to re-run tests with build from Sep 16th. The issue is still present. The log is attached.
Ok, I finally had a chance to go through this in more detail. I believe I see the issue. If you look at the mdb_sndQ_ejb.jar.jboss.xml descriptor for the test, notice the resource-ref for the connection factory in use:
<resource-ref>
<res-ref-name>jms/MyQueueConnectionFactory</res-ref-name>
<jndi-name>jms/QueueConnectionFactory</jndi-name>
</resource-ref>
This is the connection factory that is being used in the MDBTest Session Bean . We can see from the startup EAP logs the following entry:
2011-09-12 15:57:36,617 INFO [org.jboss.resource.deployment.AdminObject:296] (main) Bound admin object 'org.apache.qpid.ra.admin.QpidConnectionFactoryProxy' at 'jms/QueueConnectionFactory'
Note, this is NOT a JCA connection factory but a proxy which is meant to be used outside of the application server as per the README file.
'QpidConnectionFactoryProxy
The QpidConnectionFactoryProxy allows for a non-JCA ConnectionFactory to be bound into the JNDI tree. This ConnectionFactory can in turn be used outside of the application server. Typically ConnectionFactory of this sort is used by Swing clients.'
Note, the JNDI names are the same. So, in the MDB test when this CF is used:
cf = (ConnectionFactory)context.lookup("java:comp/env/jms/MyQueueConnectionFactory");
what you are actually using is a non-XA connection factory that is not even JCA.
A quick check in the JMX Console should reveal this. This would explain the lack of transactional support in the test, and as per Gordon's comments, why messages are never being delivered as a 'commit' command is never being sent since automatic transaction enlistment is not being invoked.
Hi, thanks for spotting this. I must be completely blind missing the prefix between jms/QueueConnectionFactory when I meant QueueConnectionFactory. It seems it is working now - I tried with one sample. I am closing the bug now and re-open if it happens again next time Thanks for checking. No worries. It's very easy to miss actually, the TCK configuration leaves a lot to be desired and it's not trivial to sport config errors due to the XSLT process to configure etc. |