qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Robie <jonathan.ro...@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 Tue, 04 Jan 2011 22:26:05 GMT
On 01/04/2011 03:47 PM, Gordon Sim wrote:

>> URL: http://svn.apache.org/viewvc?rev=1052086&view=rev
>> Log:
>> Added logging to QMF console connections.
>>
>> Warning if a broker can not be found, error if SASL authentication
>> fails or other connection errors when connecting to an existing
>> broker. Default log level is ERROR.
>
> What is the usual default for the log level (i.e. what is the default
> for other uses of the log module)? It seems a little odd to set the log
> level to error on most tools, perhaps that's just me...

It's easy to change the default.

I'm not sure what the default log level should be for QMF console 
applications - what would you suggest?

>> qpid-printevents allows the log level to be set.
>
> What about the other tools? Is it not useful for them to also be able to
> set the logging level? (As the topic of consistency came up recently,
> should the -v/--verbose option in qpid-route by rationalised with this?)

It would be easy to add the log level option to the other tools.

When I raised the topic of consistency in options recently, you 
suggested we should start by determining which tools we need and 
designing the right tool set. I'd like to avoid making changes that are 
not backwards compatible until we actually do that redesign.

Ideally, I'd probably just use logging levels in qpid-route. But for 
now, I'm reluctant to eliminate -v if there are scripts that might use it.

>> It also allows the user to specify that a connection is required, in
>> which case it terminates if a connection can not be established.
>
> I'm not mad on the name of this new option (i.e. require-connection). It
> seems like allow-reconnect or exit-on-failure would communicate a little
> more on the purpose of the option.

It's more like exit-on-connection-failure, but that's rather verbose.

To me, exit-on-failure fails to communicate that this has to do with 
connections, and allow-reconnect is not the same as exiting if a 
connection can not be established. I'm not convinced that either of 
these really does a better job of explaining the purpose.

>> Modified: qpid/trunk/qpid/extras/qmf/src/py/qmf/console.py
>> URL:
>> + if e[0] == -2:
>> + log.warning("Could not connect to broker " + self.host + ":" +
>> str(self.port) + " " + str(e))
>> + else:
>> + log.error("Could not connect to broker " + self.host + ":" +
>> str(self.port) + " " + str(e))
>> +
>
> What's the above if/else actually checking? Is there a way to make the
> code more obvious to a casual reader?

I agree. I'll try to improve that.

Jonathan

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


Mime
View raw message