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:[email protected]
