Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 623198 - Destinations created trough ADDR syntax in java are always exclusive and auto-delete
Destinations created trough ADDR syntax in java are always exclusive and auto...
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Rajith Attapattu
MRG Quality Engineering
Depends On:
  Show dependency treegraph
Reported: 2010-08-11 11:06 EDT by Jiri Kolar
Modified: 2011-03-07 10:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-03-07 10:46:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Kolar 2010-08-11 11:06:09 EDT
Description of problem:
When you create destination (topic or queue) dynamically trough ADDR syntax in Java code, even when you set auto-delete and exclusive options to false , created destinations have auto-delete and exclusive enabled.
other options defined in x-declare section seems to work fine.

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

How reproducible:

Steps to Reproduce:
1. create dynamic destination:


   Destination queue = ssn.createQueue("sales");

   String addr = "ADDR:amq.direct/x512; {create: receiver, " +
        "link : {name : 'MY.RESP.QUEUE', " + 
        "x-declare : { auto-delete: false, exclusive: false, " +
                     "'qpid.max_size': 1000, 'qpid.policy_type': ring } } }";
   Destination queue = ssn.createQueue(addr);

   Destination topic =  ssn.createTopic("use.news");

   String addr = "ADDR:vehicles/bus; " + 
        "{ " + 
          "create: always, " +                        
          "node: " + 
          "{" +
               "type: topic, " +
               "x-declare: " +
               "{ " + 
                   "type:direct, " + 
                   "auto-delete: true, " +
                   "'qpid.msg_sequence': 1, " +
                   "'qpid.ive': 1" + 
               "}" +
          "}, " +
          "link: {name : my-topic, " +
              "x-bindings: [{exchange : 'vehicles', key : car}, " +
                           "{exchange : 'vehicles', key : van}]" + 
          "}" + 

     Destination topic = ssn.createTopic(addr);    

2.When this java code is running and client for example send messages, check queues

qpid-config queues
Actual results:
Queues dynamically created have exclusive and auto-delete flag set, even when they should not. And they disappear after session is closed (auto-delete)

Expected results:
they should follow what is set in x-declare section. For example disable auto-delete or exclusive

Additional info:

This i found during verification of bz616457 but since the bug is about presence of ADDR syntax, i created extra bug for this
Comment 2 Rajith Attapattu 2011-03-07 10:46:10 EST
Topics created will always be marked auto-delete and exclusive irrespective of whether auto-delete and exclusive are marked false in the addressing string.

In JMS Topics are meant to be transient and implemented using private temp queues that are tied to the life of the subscriber. i.e when the subscriber is closed, the queue associated with the subscriber will be deleted as well.

If you need the topic to be around after the subscriber becomes inactive (ex after a connection loss) and still retain the messages, then you need to use DurableSubscriptions.

When a durable subscription is used, the topics are marked durable & exclusive but not auto-delete. Therefore the queue associated with the topic will be around until explicitly deleted by the subscriber via the unsubscribe method.

If you need to have a shared queue (i.e exclusive false) then people use 'Queues' instead of 'Topics'. If that Queue needs to be bound to the amq.topic exchange for some reason, then you could easily use x-bindings in the node properties to achieve that.

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