Bug 735030

Summary: After deploying AdminObject for queue in EAP queue is not created on qpid side
Product: Red Hat Enterprise MRG Reporter: Jiri Sedlacek <jsedlace>
Component: qpid-jcaAssignee: messaging-bugs <messaging-bugs>
Status: CLOSED CURRENTRELEASE QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 2.0CC: astitcher, iboverma, oskutka, wprice
Target Milestone: 2.1.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 499109, 700494    
Bug Blocks:    
Attachments:
Description Flags
Updated examples to aid in testing
none
Trace log from server none

Description Jiri Sedlacek 2011-09-01 08:45:54 UTC
Description of problem:
If the AdminObject for the queue is deployed, it can be used (by checking JNDI) for sending messages. 
If the message producer is the first user of the queue, on the qpid side does not exist corresponding queue, message is sent WITHOUT ANY ERROR and is not in the queue on the qpid side. 

If the consumer connects as the first user, queue on qpid side is created and messages can be and are delivered.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. download and unzip eap-5.1.1
2. deploy mrg jca resource adapter and one jms queue
3. send message to this queue
4. check qpid-stat -q on the mrg server side, you cannot see any queue with any message.
  
Actual results:

after deploying jms queue as a admin object, nothing can be seen with qpid-stat -q command

Expected results:

It will be useful to have everything created after deployment, not when queues are used for the first time.
Additional info:

Comment 1 Weston M. Price 2011-09-01 15:20:40 UTC
I am not sure I understand the sentence:

'If the message producer is the first user of the queue, on the qpid side does
not exist corresponding queue,'

Could you clarify as well as provide your *-ds.xml file for your AdminObject?

Comment 2 Jiri Sedlacek 2011-09-02 08:54:23 UTC
Weston, 

You can use *-ds.xml from qpid-java-jca examples, just configure the build.xml
to use correct eap server and profile and mrg url.

The behavior is below:

after deployment of *-ds.xml and before sending message:

[jsedlace@mrg01 ~]$ qpid-stat -q
Queues
  queue                                              dur  autoDel  excl  msg    msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
  reply-mrg01.mw.lab.eng.bos.redhat.com.7336.1            Y        Y        0     58     58       0   22.2k    22.2k        1     2
  topic-mrg01.mw.lab.eng.bos.redhat.com.7336.1            Y        Y        0      0      0       0      0        0         1     4
  qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda           Y        Y        0     26     26       0    442      442         1     4
  qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7336.1       Y        Y        0      0      0       0      0        0         1     1
  qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7336.1       Y        Y        0      1      1       0    227      227         1     2
  qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7336.1          Y        Y        0     13     13       0   76.2k    76.2k        1     2

after sending message no change:

[jsedlace@mrg01 ~]$ qpid-stat -q
Queues
  queue                                              dur  autoDel  excl  msg    msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
  qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda           Y        Y        0     28     28       0    476      476         1     4
  qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7352.1       Y        Y        0      0      0       0      0        0         1     1
  topic-mrg01.mw.lab.eng.bos.redhat.com.7352.1            Y        Y        0      0      0       0      0        0         1     4
  qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7352.1          Y        Y        0     13     13       0   77.0k    77.0k        1     2
  reply-mrg01.mw.lab.eng.bos.redhat.com.7352.1            Y        Y        0     58     58       0   22.2k    22.2k        1     2
  qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7352.1       Y        Y        0      0      0       0      0        0         1     2

after deploying MDB configured to listen to the queue/Hello - queue created with 15 cons:
[jsedlace@mrg01 ~]$ qpid-stat -q
Queues
  queue                                              dur  autoDel  excl  msg    msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
  qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7403.1       Y        Y        0      0      0       0      0        0         1     1
  qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7403.1          Y        Y        0     13     13       0   97.0k    97.0k        1     2
  qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda           Y        Y        0     32     32       0    544      544         1     4
  reply-mrg01.mw.lab.eng.bos.redhat.com.7403.1            Y        Y        0     58     58       0   22.2k    22.2k        1     2
  topic-mrg01.mw.lab.eng.bos.redhat.com.7403.1            Y        Y        0      0      0       0      0        0         1     4
  qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7403.1       Y        Y        0      0      0       0      0        0         1     2
  amq.direct                                                                0      0      0       0      0        0        15     2


after sending message this time, message is received: 
[jsedlace@mrg01 ~]$ qpid-stat -q
Queues
  queue                                              dur  autoDel  excl  msg    msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
  qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda           Y        Y        0     34     34       0    578      578         1     4
  reply-mrg01.mw.lab.eng.bos.redhat.com.7415.1            Y        Y        0     58     58       0   22.2k    22.2k        1     2
  topic-mrg01.mw.lab.eng.bos.redhat.com.7415.1            Y        Y        0      0      0       0      0        0         1     4
  qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7415.1       Y        Y        0      0      0       0      0        0         1     2
  qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7415.1       Y        Y        0      0      0       0      0        0         1     1
  qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7415.1          Y        Y        0     13     13       0   33.9k    33.9k        1     2
  amq.direct                                                                0      1      1       0     13       13        15     2

Comment 3 Weston M. Price 2011-09-02 10:05:03 UTC
Ok, I think there may be some misunderstanding here in regards to configuration and QPID in general:

amq.direct is an exchange not a queue. So, when you initially deploy the *-ds.xml file nothing is created because amq.direct is again, not a queue but is an exchange that must exist in all AMQP compliant brokers.

If you execute qpid-stat -e you will see something like the following:

[wmprice@mrgm1 ~]$ qpid-stat -e
Exchanges
  exchange            type     dur  bind  msgIn  msgOut  msgDrop  byteIn  byteOut  byteDrop
  ===========================================================================================
  qmf.default.topic   topic            1  9.93k     0    9.93k    5.56m      0     5.56m
  amq.direct          direct   Y       1    59     68       0     22.3k   22.4k       0
                      direct           5     0      0       0        0       0        0
  amq.topic           topic    Y       0     0      0       0        0       0        0
  amq.fanout          fanout   Y       0     0      0       0        0       0        0
  amq.match           headers  Y       0     0      0       0        0       0        0
  qpid.management     topic            3  9.93k     0    9.93k    1.54m      0     1.54m
  qmf.default.direct  direct           1     9      9       0     2.34k   2.34k 

Note the existence of the amq.direct exchange. 

At some point in your testing, you have inadvertently create a queue called amq.direct. This is causing the behavior you are seeing. 

A word about the examples:

The example code is meant as a starter point for development, not an end in and of itself. When configuration destinations, you should really not use amq.direct for your testing as this is an exchange, not a queue. For a simple example, use something like the following in your *-ds.xml file:


 <mbean code="org.jboss.resource.deployment.AdminObject"
         name="qpid.jca:name=HelloQueue">
     <attribute name="JNDIName">HelloQueue</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
        destinationType=QUEUE
        destinationAddress=hello;{create:always,node:{type:queue}}
     </attribute>
  </mbean>

Which would result in something like:

Queues
  queue                    dur  autoDel  excl  msg   msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ========================================================================================================
  topic-mrgm1.6037.1            Y        Y        0     0      0       0      0        0         1     4
  qmfc-v2-mrgm1.6037.1          Y        Y        0    11     11       0   24.1k    24.1k        1     2
  qmfc-v2-ui-mrgm1.6037.1       Y        Y        0     0      0       0      0        0         1     1
  qmfc-v2-hb-mrgm1.6037.1       Y        Y        0     0      0       0      0        0         1     2
  reply-mrgm1.6037.1            Y        Y        0    58     58       0   22.2k    22.2k        1     2
  hello                                           0     0      0       0      0        0        10     1


Obviously, you can use whatever name you like. 

I believe there are other bugs that have been filed as a result of this syntax/destination issue. I will go back and review. If this explanation is sufficient for you, you can close this bug.

Comment 4 Jiri Sedlacek 2011-09-02 12:11:07 UTC
Weston, 

destinationAddress=hello;{create:always,node:{type:queue}} cannot be used with this version of jca adapter. But we need to define queues/topics in correct way, so it would be useful to prepare some verified and working examples, how to configure admin object, which we can use.

Comment 5 Weston M. Price 2011-09-02 12:15:23 UTC
Example for a queue

direct://amq.direct//hello.Queue

Note the use of the the direct exchange class, the exchange itself and the queue

Topic

topic://amq.topic//hello.Topic?routingKey='hello.Topic'

I am providing the same description here:

https://bugzilla.redhat.com/show_bug.cgi?id=734059

Comment 6 Jiri Sedlacek 2011-09-02 12:43:51 UTC
Queue is configured in this way 

direct://amq.direct//hello.Queue

but the problem is the same, until first consumer is connected to the queue, you can send thousands of messages, which ends in the black hole. 

Next problem is missing routingKey for the queue in your example above. If I configure two queues in this way, message send to one is delivered into both.

Comment 7 Weston M. Price 2011-09-02 13:10:19 UTC
'but the problem is the same, until first consumer is connected to the queue,
you can send thousands of messages, which ends in the black hole. '

If no one is listening on that destination, messages will not be delivered. This is the expected behavior. Once you deploy your MDB(s), the message(s) will be delivered once they are deployed and activated. 
Note, the messages don't go into a 'black hole', the are enqueued and will be delivered when you deploy.

'Next problem is missing routingKey for the queue in your example above. If I
configure two queues in this way, message send to one is delivered into both.'

Why would you do this? This would be a misconfiguration. If you want a different routing key, simply add it as per the BURL syntax. The example I gave assumed one queue, not multiples.

direct://amq.direct//hello.Queue?routingKey='hello.Queue.key1'

direct://amq.direct//hello.Queue?routingKey='hello.Queue.key2'

Remember, you need to have separate AdminObjects for each of these:


 <mbean code="org.jboss.resource.deployment.AdminObject"
         name="qpid.jca:name=HelloQueue1">
     <attribute name="JNDIName">HelloQueue</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
        destinationType=QUEUE
        destinationAddress=direct://amq.direct//hello.Queue?routingKey='hello.Queue.key1'
     </attribute>
  </mbean>


 <mbean code="org.jboss.resource.deployment.AdminObject"
         name="qpid.jca:name=HelloQueue2">
     <attribute name="JNDIName">HelloQueue</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
        destinationType=QUEUE
        destinationAddress=direct://amq.direct//hello.Queue?routingKey='hello.Queue.key2'
     </attribute>
  </mbean>


Similarly you would have a two listeners (MDB's), one bound to Hello1, the other bound to Hello2.

@ActivationConfigProperty(propertyName = "destination", propertyValue = "HelloQueue1"),
public class FirstListener implements MessageListener
{
}


@ActivationConfigProperty(propertyName = "destination", propertyValue = "HelloQueue2"),
public class SecondListener implements MessageListener
{
}

Comment 8 Jiri Sedlacek 2011-09-02 13:47:00 UTC
>>If no one is listening on that destination, messages will not be delivered.
>>This is the expected behavior. Once you deploy your MDB(s), the message(s) will
>>be delivered once they are deployed and activated. 
>>Note, the messages don't go into a 'black hole', the are enqueued and will be
>>delivered when you deploy.'

This is the way it should work, but it's not. If the queue was not used never before, and the producer is the first user of the jms queue, messages are not delivered later when MDB is connected. Try it.



Second problem, two queues:

<mbean code="org.jboss.resource.deployment.AdminObject"
     name="qpid.jca:name=qAA">
     <attribute name="JNDIName">queue/AA</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
          destinationAddress=direct://amq.direct//hello.aa
          destinationType=queue
     </attribute>
</mbean>

<mbean code="org.jboss.resource.deployment.AdminObject"
     name="qpid.jca:name=qBB">
     <attribute name="JNDIName">queue/BB</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
          destinationAddress=direct://amq.direct//hello.bb
          destinationType=queue
     </attribute>
</mbean>

two MDBs:

@MessageDriven(activationConfig = {
		@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/AA"),
		@ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'") 
		}, mappedName = "jms/firstMdb")
@ResourceAdapter("qpid-ra-0.10.rar")



@MessageDriven(activationConfig = {
		@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
		@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
		@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/BB"),
		@ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'") 
		}, mappedName = "jms/secondMdb")
@ResourceAdapter("qpid-ra-0.10.rar")


One message send to queue/AA

two messages received, one by first MDB, second by second MDB. Is this OK?

Comment 9 Weston M. Price 2011-09-02 13:53:14 UTC
'This is the way it should work, but it's not. If the queue was not used never
before, and the producer is the first user of the jms queue, messages are not
delivered later when MDB is connected. Try it.'

I have and it works as expected. How are you verifying that the message is delivered? Log file, console? Do you have a system I can examine?

'two messages received, one by first MDB, second by second MDB. Is this OK?'

Yes, this is the expected behavior.

Comment 10 Jiri Sedlacek 2011-09-02 16:46:13 UTC
>>'two messages received, one by first MDB, second by second MDB. Is this OK?'

>>Yes, this is the expected behavior.

so, how to set queues that just mdb, that listen to the queue A received the message sent to queue A and other mdbs not receive it?

Comment 11 Weston M. Price 2011-09-02 17:11:35 UTC
I am setting up an example for you that shows exactly how to do it. I will attach it when complete or give you a pointer to the code.

Comment 12 Weston M. Price 2011-09-02 17:49:33 UTC
Also, for the two messages issue, I need to see the MDB's (there should be two) you are using.

Comment 13 Weston M. Price 2011-09-02 17:54:58 UTC
Ok, sorry, my eyes are a bit tired, I just saw the MDB's. 

All things considered, this 'should' work. I have a similar example working with no issues. The only thing I can think of is if you still have the old 'amq.direct' queue in the system, this might cause the problem. Did you try restart your broker to make sure that isn't there?

Comment 14 Weston M. Price 2011-09-03 23:12:52 UTC
Ok, I did some debugging, and I was finally able to reproduce the issue(s) that you are seeing. There are a few issues which can be easily resolved:

1)Make absolutely certain that you do not have a queue named amq.direct in your system. The original configuration for the example code could possible create an amq.direct queue (not exchange) and this causes real problems. Sometimes it's easy to forget, run qpid-stat -q often and verify that amq.direct is not there. If it is:

qpid-config --force del queue amq.direct

2) If you make modifications to the qpid-jca-ds.xml file you MUST (no, this is not an option), either reboot your server, or redeploy your application. Note, this is NOT a Qpid JCA issue but is inherent in the JBoss EAP implementation, in other words, this is applicable for any adapter JDBC, JMS etc

3) You MUST provide a routing key for each destination:
destinationAddress=direct://amq.direct//hello.aa?routingkey='hello.aa'
destinationAddress=direct://amq.direct//hello.bb?routingkey='hello.bb'

Here is what I am doing:

Example:

Here we have two queue's Hello and GoodBye

<mbean code="org.jboss.resource.deployment.AdminObject"
         name="qpid.jca:name=HelloQueue">
     <attribute name="JNDIName">HelloQueue</attribute>
     <depends
optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
        destinationType=QUEUE
        destinationAddress=direct://amq.direct//hello.Queue?autodelete='true',routingkey='hello.Queue'
     </attribute>
  </mbean>

@MessageDriven(activationConfig = {
     @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue
= "Auto-acknowledge"),
     @ActivationConfigProperty(propertyName = "destinationType", propertyValue
= "javax.jms.Queue"),
     @ActivationConfigProperty(propertyName = "destination", propertyValue =
"HelloQueue"),
     @ActivationConfigProperty(propertyName = "connectionURL", propertyValue =
"amqp://anonymous:@client/test?brokerlist='tcp://10.0.1.44:5672?sasl_mechs='ANONYMOUS''"),
           @ActivationConfigProperty(propertyName = "maxSession", propertyValue
= "10")

})
public class QpidHelloListenerBean implements MessageListener 


<mbean code="org.jboss.resource.deployment.AdminObject"
         name="qpid.jca:name=GoodByeQueue">
     <attribute name="JNDIName">GoodByeQueue</attribute>
     <depends
optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
        destinationType=QUEUE
        destinationAddress=direct://amq.direct//goodbye.Queue?autodelete='true',routingkey='goodbye.Queue'
     </attribute>
  </mbean>

@MessageDriven(activationConfig = {
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "destination", propertyValue =
"GoodByeQueue"),
        @ActivationConfigProperty(propertyName = "connectionURL", propertyValue
=
"amqp://anonymous:@client/test?brokerlist='tcp://10.0.1.44:5672?sasl_mechs='ANONYMOUS''"),
        @ActivationConfigProperty(propertyName = "useLocalTx", propertyValue =
"false"),
        @ActivationConfigProperty(propertyName = "maxSession", propertyValue =
"10")

})
public class QpidGoodByeListenerBean implements MessageListener


start EAP:

14:26:51,613 INFO  [AdminObject] Bound admin object
'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'HelloQueue'
14:26:51,620 INFO  [AdminObject] Bound admin object
'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'GoodByeQueue'

Send a message with client either web or RMI, here we are sending one message to the HelloQueue destination:

ant -Dtarget.platform=jboss run-client

[java] 1124 [main] DEBUG org.apache.qpid.jca.example.client.QpidTestClient  - Sending 1 message(s) with content: Hello, World! with destination  HelloQueue

Server:

19:05:19,107 INFO  [QpidHelloListenerBean] Received text message with contents Hello, World! at Sat Sep 03 19:05:19 EDT 2011

Note, only the HelloMDB received the message. Now, let's send one to the GoodByeQueue

[java] 1170 [main] DEBUG org.apache.qpid.jca.example.client.QpidTestClient  - Sending 1 message(s) with content: Hello, World! with destination  GoodByeQueue

19:08:20,431 INFO  [QpidGoodByeListenerBean] Received text message with contents Hello, World! at Sat Sep 03 19:08:20 EDT 2011

I am sure I can help you with this but I just wanted to show you the process and config I am using. Let know if I can help.

Comment 15 Weston M. Price 2011-09-05 08:53:21 UTC
I am attaching jca-examples.jar which is a rework of the JCA examples providing
much more realistic examples for Queue/Topics, syntax etc. This should give
better examples that what was previously provided. There is a BZ for this
735322, but I thought I would get the work out early so you can start taking a
look. 

Alternatively you can check it out from GitHub as well:

git://github.com/astitcher/qpid-jca.git

branch is wp-BZ-735322

Comment 16 Weston M. Price 2011-09-05 08:53:50 UTC
Created attachment 521454 [details]
Updated examples to aid in testing

Comment 17 Jiri Sedlacek 2011-09-05 10:02:08 UTC
>>3) You MUST provide a routing key for each destination:
>>destinationAddress=direct://amq.direct//hello.aa?routingkey='hello.aa'
>>destinationAddress=direct://amq.direct//hello.bb?routingkey='hello.bb'

That's exactly what we need to know, thanks, the second problem is resolved.

The first problem still remains:
Situatuin is:
clean server, no user queue visible in qpid-stat -q listing

I deploy this queue

<mbean code="org.jboss.resource.deployment.AdminObject"
     name="qpid.jca:name=qAA">
     <attribute name="JNDIName">queue/AA</attribute>
     <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
     <attribute name="Type">javax.jms.Destination</attribute>
     <attribute name="Properties">
          destinationAddress=direct://amq.direct//hello.aa?autodelete='true',routingkey='hello.aa'
          destinationType=queue
     </attribute>
</mbean>

no change in qpid-stat -q listing
no line in qpid-printevents listing, so probably nothing happen on qpid side

deployed MRGConnectionFactory:

<mbean code="org.jboss.resource.deployment.AdminObject"
      name="qpid.jca:name=MRGConnectionFactory">
    <attribute name="JNDIName">MRGConnectionFactory</attribute>
    <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
    <attribute name="Type">javax.jms.ConnectionFactory</attribute>
    <attribute name="Properties">
            connectionURL=amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'
    </attribute>
  </mbean>

one message sent to the queue with standalone client, (by getting MRGConnectionFactory from JNDI and getting destination queue/AA from JNDI)

no change in qpid-stat -q listing

listing of qpid-printevents show 2 lines:
Mon Sep  5 09:52:35 2011 INFO  org.apache.qpid.broker:clientConnect broker=localhost:5672 rhost=10.16.88.240:5672-10.34.3.11:46540 user=guest@QPID
Mon Sep  5 09:52:36 2011 INFO  org.apache.qpid.broker:clientDisconnect broker=localhost:5672 rhost=10.16.88.240:5672-10.34.3.11:46540 user=guest@QPID

simple MDB bind to queue/AA deployed, queue is now visible in qpid-stat -q:

queue                                               dur  autoDel  excl  msg   msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
...
  hello.aa                                                 Y                 0     0      0       0      0        0        15     2
...

one message sent with simple standalone client, this time is visible in qpid-stat -q, that message was sent.
Queues
  queue                                               dur  autoDel  excl  msg   msgIn  msgOut  bytes  bytesIn  bytesOut  cons  bind
  ===================================================================================================================================
...
  hello.aa                                                 Y                 0     1      1       0     40       40        15     2
...

Everything has default configuration, nothing special is used, /etc/qpidd.conf contains just 3 lines:
cluster-mechanism=ANONYMOUS
truncate=yes
auth=no

Comment 18 Weston M. Price 2011-09-05 10:10:40 UTC
Can you run a trace on the Broker? 

Something along the lines of 

 qpidd --log-enable info+ --log-enable trace+:amqp_0_10

I am going to try and reproduce this on my end.

Comment 19 Weston M. Price 2011-09-05 10:24:02 UTC
I just tried reproducing this and I cannot. Did you restart your Broker and make sure everything was clean before running the test? I started from a completely clean system, and again, I can not reproduce this issue.

Comment 20 Jiri Sedlacek 2011-09-05 10:37:20 UTC
Created attachment 521473 [details]
Trace log from server

Log is attached, sequence of activities was:

start qpidd
deploy queue/AA
send message with standalone client
deploy MDB bound to queue/AA
send message with standalone client

Comment 21 Jiri Sedlacek 2011-09-05 10:41:18 UTC
Yes, restarted broker, everything was clean.

Info for package qpid-cpp-server

Installed Packages
Name       : qpid-cpp-server
Arch       : x86_64
Version    : 0.10
Release    : 3.el5
Size       : 3.3 M
Repo       : installed
Summary    : An AMQP message broker daemon
URL        : http://qpid.apache.org
License    : ASL 2.0
Description: A message broker daemon that receives stores and routes messages using
           : the open AMQP messaging protocol.


I can ask for update to current version.

Comment 22 Weston M. Price 2011-09-05 10:51:31 UTC
start qpidd
deploy queue/AA
send message with standalone client
deploy MDB bound to queue/AA
send message with standalone client

Ok, this is a different

start-qpidd --> No problems here clean system
deploy queue/AA --> Here is the issue, the queue is not created by default 

In fact, I don't believe there is a way to create a destination on deployment using the BURL syntax as this is an ADDR option only from what I know. Rajith would better be able to answer this. However, if this is indeed the case, they we are going to need to get 

https://bugzilla.redhat.com/show_bug.cgi?id=700494

in place before we support this. Otherwise, you will have to create the destinations manually if you want to use the older syntax.

Comment 23 Weston M. Price 2011-09-06 15:56:04 UTC
Again, this isn't supported by BURL, I confirmed this with the JMS client team this morning. So, we will have to upgrade the adapter to support this.

Comment 24 Jiri Sedlacek 2011-09-06 17:38:36 UTC
Ok, we have temporary workaround, which let us do testing, but for customers it will be definitely necessary to have it there.

Thanks for investigation.

Comment 25 Weston M. Price 2011-09-06 17:39:50 UTC
No problem, again, I don't necessarily disagree with you. We can treat it as a feature request moving forward. Thanks for your work on this one, I know it wasn't easy.

Comment 26 Andrew Stitcher 2011-09-06 19:25:52 UTC
if this is a feature request please change the target release to 2.2

Comment 27 Weston M. Price 2011-09-08 17:57:08 UTC
I just submitted the latest build of the Qpid JCA adapter which has the fix to use ADDR syntax for destinations. This should address:

https://bugzilla.redhat.com/show_bug.cgi?id=700494

and allow you to continue testing now that you can use ADDR syntax with the adapter.

Comment 28 Andrew Stitcher 2011-09-08 18:14:50 UTC
I'm a little confused by this bug report, but are we saying that fixing this bug is dependent on fixing Bug 700494? If so we should make this bug dependent on that one.

Comment 29 Weston M. Price 2011-09-08 18:38:52 UTC
Adding dependency on Bug 700494

Comment 30 Weston M. Price 2011-09-12 11:25:34 UTC
ADDR syntax included as part of the new adapter build. This should be addressed with the new code and Bug 700494.

Comment 31 Andrew Stitcher 2011-09-22 13:30:32 UTC
This has been fixed in package qpid-java-jca-0.10-10

Comment 32 Jiri Sedlacek 2011-11-08 08:54:24 UTC
Setting to verified for the second time.