Bug 740847 - TCK tests mdb_exceptT are failing
Summary: TCK tests mdb_exceptT are failing
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-jca
Version: 2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: 2.0.4
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-23 14:18 UTC by Jiri Pechanec
Modified: 2011-10-19 21:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-19 21:46:04 UTC
Target Upstream Version:

Attachments (Terms of Use)
TCK Test results (42.42 KB, application/x-gzip)
2011-09-23 14:18 UTC, Jiri Pechanec
no flags Details
TCK Test application (48.00 KB, application/x-gzip)
2011-09-23 14:19 UTC, Jiri Pechanec
no flags Details
EAP server log (2.95 MB, application/x-gzip)
2011-09-23 14:21 UTC, Jiri Pechanec
no flags Details

Description Jiri Pechanec 2011-09-23 14:18:58 UTC
Created attachment 524627 [details]
TCK Test results

The MDB related to topics in this package are failing. The EAP server log contains NullPointerExceptions that relates to this issue
2011-09-23 07:11:39,925 WARN  [org.apache.qpid.ra.inflow.QpidActivation:363] (WorkManager(3)-4) Failure in Qpid activation org.apache.qpid.ra.inflow.QpidActivationSpec(ra=org.apache.qpid.ra.QpidResourceAdapter@1a1d0ff destination=jms_ee_mdb_mdb_exceptT_MDB_DURABLE_BMT destinationType=javax.jms.Topic ack=Auto-acknowledge durable=true clientID=cts4 user=null maxSession=15)
        at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
        at org.apache.qpid.client.AMQSession.createDurableSubscriber(AMQSession.java:1075)
        at org.apache.qpid.ra.inflow.QpidMessageHandler.setup(QpidMessageHandler.java:98)
        at org.apache.qpid.ra.inflow.QpidActivation.setup(QpidActivation.java:309)
        at org.apache.qpid.ra.inflow.QpidActivation$SetupActivation.run(QpidActivation.java:581)
        at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
        at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

The issue is reproducible by executing only the failing tests

Comment 1 Jiri Pechanec 2011-09-23 14:19:48 UTC
Created attachment 524628 [details]
TCK Test application

Comment 2 Jiri Pechanec 2011-09-23 14:21:39 UTC
Created attachment 524630 [details]
EAP server log

Comment 3 Weston M. Price 2011-10-19 21:46:04 UTC
There are a couple of issues I can see that don't seem to be TCK related:

As per the JMS 1.1 API 

'Sessions with durable subscribers must always provide the same client identifier. In addition, each client must specify a name that uniquely identifies (within client identifier) each durable subscription it creates. Only one session at a time can have a TopicSubscriber for a particular durable subscription.'

1) In the case of a durable subscriber, both a clientId and a subscription name need to be provided to uniquely identify the client as per the API doc above. 

Something along the lines of 

 @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "some.name"),

2) Being that only one session at a time can have a TopicSubscriber for a particular durable subscription, the maxSessions property should be reduced to 1. 

This should cover this particular issue. Being that this is config related, I am going to close it as 'not a bug'. Should this not be sufficient, please feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.