qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: svn commit: r1052086 - in /qpid/trunk/qpid: extras/qmf/src/py/qmf/console.py tools/src/py/qpid-config tools/src/py/qpid-printevents tools/src/py/qpid-stat tools/src/py/qpid-tool
Date Wed, 05 Jan 2011 18:12:48 GMT
On 01/05/2011 03:50 PM, Ken Giusti wrote:
> Hi Gordon,
> Jonathan discussed some of these issues with me before working on
> this change.  Some of the changes here are due to the current state
> of the underlying python qmf implementation (console.py) used by
> these command line tools.
> Couple of things to keep in mind re: the qmf implementation used by
> these tools:
> console.py provides two usage models, which are reflected by the
> behavior of command line tools.  console.py can be used for a
> synchronous command-response tool (like qpid-route, qpid-config), or
> it can be used as a passive monitor (qpid-tool, qpid-printevents).
> Connection failures when using qmf in the synchronous mode are
> reported back immediately to the application, which deals with them
> appropriately. No issue there.
> However, there's an ambiguity with the passive approach: what should
> happen when the connection to the broker fails?   The nature of the
> qpid-printevents/qpid-tool allows them to be run in lieu of a broker
> being available.  A user can run the tool indefinitely, allowing
> brokers to come and go over time.


> Having a connection attempt fail due to broker not being available,
> or going away, isn't really a hard error in this model.  qmf merely
> notifies the application that the broker has disconnected, and keeps
> retrying the connection.  However, that's a problem when the failure
> may involve a misconfiguration - say invalid credentials - as qmf
> will retry indefinitely until a human intervenes to fix the
> misconfiguration.
> Part of what these changes attempt to alert the user to a hard
> connection failure rather than a transient broker availability issue
> when qmf is used in passive mode.
> Which brings us to logging in qmf:  There currently isn't any
> logging, which makes it hard for a user to determine the underlying
> cause of a failure to connect with a broker.  Part of these changes
> are an attempt to provide more visibility in this area.

Understood. Logging more detail on connection failures seems reasonable 

My comments/questions are more on the rationale behind the particular 
changes in this commit. E.g. the decision on whether to log it as a 
warning or error, the setting of a log-level in several other tools for 
what is essentially at present one line, the point of the log-level 
option in qpid-printevents and how it fits in (or doesn't) with that 
tools other outputs etc.

There are already callbacks from the console api that qpid-printevents 
uses to log connection and disconnection already. Providing more detail 
on the reason for disconnection there would seem a reasonable approach 
to me. The broker object passed in to the callback has an error 
attribute that contains a description of the last problem. Potentially 
that or some enhancement of it could be used.

The callbacks don't get triggered if the tool never connects at present. 
Perhaps there is (or should be) some way to get a callback when the 
connection cannot be established?

In summary, it doesn't seem to me that these changes represent the 
cleanest, simplest, most useful or most elegant solution to the stated 

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message