Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1155553

Summary: qpid-tool to halt when initial connection to broker failed
Product: Red Hat Enterprise MRG Reporter: Pavel Moravec <pmoravec>
Component: qpid-toolsAssignee: Pavel Moravec <pmoravec>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jross, pematous, pmoravec, zkraus
Target Milestone: 3.2Keywords: Improvement, TestCaseProvided
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: qpid-tools-0.32-1 Doc Type: Bug Fix
Doc Text:
When the +qpid-tool+ was run with invalid credentials or an incorrect host name, the tool did not raise an exception or warning. This lack of context left the user with the impression that the tool connected successfully, when this was not the case. +qpid-tool+ now prints a warning to stdout: `qpid: Failed to connect: Exception during connection setup: error - [Errno 111]` if incorrect parameters are passed while the broker is not running.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-08 13:09:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pavel Moravec 2014-10-22 11:13:49 UTC
Description of problem:
When I mistype brokerURL in e.g. qpid-stat, I get some error (ConnectError or AuthenticationFailure). But when I invoke qpid-tool with invalid credentials or hostname, the tool raises no exception or warning, leaving the user under wrong assumption the tool has connected successfully.


Version-Release number of selected component (if applicable):
qpid-tools-0.30-1.el6.noarch


How reproducible:
100%


Steps to Reproduce:
0. start qpid broker with auth=yes and guest/guest credentials in sasldb
1. qpid-tool invalid_hostname
2. qpid-tool guest/wrongpassword@localhost


Actual results:
No indication qpid-tool is not connected


Expected results:
qpdi-tool to exit.


Additional info:

Comment 1 Pavel Moravec 2014-10-22 13:38:58 UTC
Upstream review request: https://reviews.apache.org/r/27032/

Comment 2 Pavel Moravec 2014-10-23 14:15:24 UTC
Committed revision 1633818.

The decision taken was qpid-tool should print warning to stdout, like:

$ ./tools/src/py/qpid-tool
Management Tool for QPID
qpid: Failed to connect: Exception during connection setup: error - [Errno 111] Connection refused

(when broker is not running)

Comment 4 Jared MORGAN 2015-07-20 06:33:08 UTC
Ahem, should really change the Rel Note status to ? so it isn't included accidentally. Please verify and let me know once the ticket passes through QA.

Comment 5 Pavel Moravec 2015-07-22 06:22:16 UTC
(In reply to Jared MORGAN from comment #4)
> Ahem, should really change the Rel Note status to ? so it isn't included
> accidentally. Please verify and let me know once the ticket passes through
> QA.

Sounds fine, just the latest line "Result:" seems to be extra.

Comment 9 Pavel Moravec 2015-08-10 06:48:47 UTC
Halting or printing to stderr would be better. But as the tool prints to stdout _any_ exception (i.e. forget to provide arguments of a method and you get:

  def do_call(self, data):
    try:
      self.dataObject.do_call(data)
    except Exception, e:
      print "Exception in do_call: %r", e

), I would say it is sufficient fix. (I havent tried the fix by myself, but I "just" say warning/exception print to stdout and nothing else is a sufficient fix for me).

Comment 10 Petr Matousek 2015-08-10 09:48:39 UTC
This fix improves qpid-tool error handling by simply printing out an error message when connection to the broker fails. Qpid-tool does not exit, that should be fine wrt comment 9. Error messages are printed to stdout instead of stderr, but this is already tracked by bug 849917 and bug 1082102.

packages:
qpid-tools-0.34-1

-> VERIFIED

Comment 12 errata-xmlrpc 2015-10-08 13:09:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-1879.html