Bug 734472

Summary: The Broker object is created using java client even if an error occurs
Product: Red Hat Enterprise MRG Reporter: Petr Matousek <pematous>
Component: qpid-javaAssignee: messaging-bugs <messaging-bugs>
Status: NEW --- QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: DevelopmentCC: iboverma, jross
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 691778 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:

Description Petr Matousek 2011-08-30 14:16:38 UTC 
+++ This bug was initially created as a clone of Bug #691778 +++

Description of problem:

When creating object using addressing (with java client), in some cases object is created even if the command for creation ends with error.

This was seen on RHEL6.1 x86_64

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

How reproducible:
100%

Steps to Reproduce:
Please see additional info
  
Actual results:
The Broker object is created even if an error occurs

Expected results:
The Broker object shall not created if an error occurs

Additional info:

# qpid-config exchanges | grep myEx_xml
# java -cp $CLASSPATH org.apache.qpid.example.Drain "myEx_xml;{create: always,node:{type: topic,x-declare:{type:xml}}}"
...
internal-error: Could not parse xquery: (qpid/xml/XmlExchange.cpp:96), errorInfo={}) [error code 541: internal error]
# echo $?
1
# qpid-config exchanges | grep myEx_xml
xml       myEx_xml           

------------- The same applies for header exchange

# qpid-config exchanges | grep myEx_headers
# java -cp $CLASSPATH org.apache.qpid.example.Drain "myEx_headers;{create: always,node:{type: topic,x-declare:{type:headers}}}"
...
internal-error: Invalid or missing x-match value binding to headers exchange. Must be a string ["all" or "any"] (qpid/broker/HeadersExchange.cpp:110)
# echo $?
1
# qpid-config exchanges | grep myEx_headers
headers   myEx_headers
Comment 1 Rajith Attapattu 2012-02-14 22:26:58 UTC 
If the exchange is created, then it's clearly a broker bug not a jms client issue.
Could you please assign it to someone from the C++ broker side and change the component to the C++ broker ?
Comment 2 Petr Matousek 2012-02-29 18:12:45 UTC 
Yes the exchange is created. I am not much familiar with the default values by xml/headers exchange creation, but maybe the right question here is: "shall the error be printed out or not?"

using the same addresses with cpp client leads to successful exchange creation (no error appears, return code is equal to zero) 
using java (and python) clients an error message is printed out, but the exchange is successfully created as well.
Comment 3 Justin Ross 2013-02-23 02:45:57 UTC 
Rajith, this doesn't look like a broker issue per se.  Please investigate.

(In reply to comment #2)
> Yes the exchange is created. I am not much familiar with the default values
> by xml/headers exchange creation, but maybe the right question here is:
> "shall the error be printed out or not?"
> 
> using the same addresses with cpp client leads to successful exchange
> creation (no error appears, return code is equal to zero) 
> using java (and python) clients an error message is printed out, but the
> exchange is successfully created as well.
Comment 4 Rajith Attapattu 2013-05-09 15:23:35 UTC 
There are two things here. 

1. The c++ and python client adds a "x-match:all" argument (for headers_ by default. Which is why it works.
The JMS client doesn't add this.

2. The queue-declare and exchange bind operations are two distinct operations.
   So we need to do one of two things.

  1. Leave the current behaviour as it is.

  2. If the exchange bind fails, then we delete the exchange or queue we created.

I will discuss this upstream.
Comment 5 Rajith Attapattu 2013-05-23 14:33:45 UTC 
I will be adding the missing binding info to make this work.