Bug 731408 - Using assert in address string leads to binding creation + different assertion behaviour
Summary: Using assert in address string leads to binding creation + different assertio...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java
Version: 2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-17 14:51 UTC by Petr Matousek
Modified: 2019-02-08 14:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Petr Matousek 2011-08-17 14:51:56 UTC
Description of problem:

Using the following command the binding amq.direct [key] => q is created: 

# java -cp $CLASSPATH org.apache.qpid.example.Drain "q; {assert:always, node: {x-bindings: [{exchange: 'amq.direct', key:'key'}]}}"

No object shall be created when only assert action is used in address string.
Error message indicating assertion failure shall be displayed, command shall end with non-zero return code.

Moreover the assertion using java client behaves another way than using other clients. Please see additional info.

Version-Release number of selected component (if applicable):
qpid-java-0.10-6

How reproducible:
100%

Steps to Reproduce:
1. qpid-config add queue q
2. java -cp $CLASSPATH org.apache.qpid.example.Drain "q; {assert:always, node: {x-bindings: [{exchange: 'amq.direct', key:'key'}]}}"
3. return code is equal to 0
4. list queue q bindings
4. there is a new binding amq.direct [key] => q
  
Actual results:
The binding is created when assert is used in address string.

Expected results:
No object shall be created when only assert action is used in address string.
Error message indicating that the assertion failed is displayed, command ends with non-zero return code.
The assertion results behaves the same way as using other clients.

Additional info:

Assertion general rules at present time:

At present the assertion only checks for capabilities requested that differ from the defaults:

i.e.
* If you have requested a durable queue, it will fail if the actual queue is non-durable. The reverse test isn't currently applied; i.e. you cannot at present assert that the queue is non-durable only that it is durable.

consider following example:

# qpid-config add queue q --durable
# java -cp $CLASSPATH org.apache.qpid.example.Drain "q;{assert:always,
node:{durable:False}}"
Exception in thread "main" javax.jms.JMSException: Error registering
consumer: org.apache.qpid.AMQException: The name 'q' supplied in the
address doesn't resolve to an exchange or a queue 

The fact that the Java client may assert that a queue is non-durable is not necessarily wrong, but it is in conflict with the definition above and with the other clients behaviour. All the clients shall behave the same way.

C++ client behaviour:

# qpid-config add queue q1
# $cppapi/drain "q1;{assert:always, node:{durable:False}}"; echo $?
0
# $cppapi/drain "q1;{assert:always, node:{durable:True}}"; echo $?
Queue not durable: q1
1

# qpid-config add queue q2 --durable
# $cppapi/drain "q2;{assert:always, node:{durable:False}}"; echo $?
0
# $cppapi/drain "q2;{assert:always, node:{durable:True}}"; echo $?
0


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