qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@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:52:29 GMT
> 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?

Ah, I like this approach: we could add a new callback method to the Console class that would
be invoked should a connection attempt fail due to a misconfiguration-type error.  That would
be safer than making a call to "brokerDisconnect()", as existing applications may not expect
a disconnect event without first getting a connect event.

There would be no api issues - it wouldn't affect existing client implementations that don't
override it.

-K

----- Original Message -----
> 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.
> 
> Understood.
> 
> > 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
> enough.
> 
> 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
> problems.
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

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


Mime
View raw message