> 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:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
