C++ broker - some newbie questions

[Robert Greig <ro...@gmail.com>]

I have been using the C++ broker for the first time when doing some
testing of the WCF client. When doing this, I have made some
observations as a "new user":

1) the broker's default output logging level is nothing. If you start
it up, it gives no indication that it is doing anything at all. Is
this deliberate? I think it should really be INFO level, or at least
some level that enables the user to see that it is listening on a port
without running netstat.

2) the broker does not complain when you give it an option that it
doesn't understand. For example:

qpidbroker /eatmoremincepies

doesn't yield any error or usage string. (After point 1, the curious
user may try to get help with the /help argument).

3) How do you configure authentication in the windows broker? The info
I read in one of the files in the distro didn't seem to apply for
windows since it involved using a tool to create users. I had to
disable authentication to get my client to run.

RG

Re: [c++]: logging levels (was Re: C++ broker - some newbie questions)

[Gordon Sim <gs...@redhat.com>]

Robert Greig wrote:
> 2009/1/2 Gordon Sim <gs...@redhat.com>:
> 
>> At present for example a warning is logged for every published message that
>> cannot be routed; every 'local' message dropped due to a 'no-local'
>> directive results in an info level log message etc. As these are per-message
>> events they could result in lots of log entries.
> 
> Yes, I can see this will be an issue.
> 
> Does your logging infrastructure have the concept of categories (like
> log4j)? It may be useful to have a *small* set of categories (not like
> log4j common usage which tends to map onto package namespaces) such as
> "general", "message-delivery", "connection" etc. and these can have
> levels controlled independently. The default for "general" would be
> INFO (say) but for "message-delivery" it could be "error+".
> 
> I think having a small set of categories is a good idea and one that
> would be nice to see in the Java world since the log level is hard to
> tweak without detailed knowledge of the code structure (effectively).

Yes, I agree. Our log statements can be filtered by a substring match on 
the file in which they occur. That is a bit tricky for those who don't 
know the code and also does not take into account the frequency of the 
event (per message, per connection or general etc).

One simple (though not very elegant) option would be to create separate 
classes for logging message level events (and perhaps session- and 
connection- level events also) with a name chosen to make it easy and 
intuitive to turn on and off.

There is some overlap between diagnostic messages of this sort and 
management events. So perhaps another approach is to treat them as 
management events and have a separate 'dimension' of configuration for 
determining how various management events are treated (E.g. log all info 
events for exchange A, but only log warnings for exchange B etc).

Thats perhaps overly complex for now. Maybe a good first step would be 
something in between these two, e.g. have the management object do the 
logging for per-message events making the component to turn on/off in 
filtering more consistent. (E.g. it would not be the particular exchange 
subclass that logged a warning about inability to route a message but 
the exchanges management object).

Re: [c++]: logging levels (was Re: C++ broker - some newbie questions)

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> 2009/1/2 Gordon Sim <gs...@redhat.com>:
>
>   
>> At present for example a warning is logged for every published message that
>> cannot be routed; every 'local' message dropped due to a 'no-local'
>> directive results in an info level log message etc. As these are per-message
>> events they could result in lots of log entries.
>>     
>
> Yes, I can see this will be an issue.
>
> Does your logging infrastructure have the concept of categories (like
> log4j)? It may be useful to have a *small* set of categories (not like
> log4j common usage which tends to map onto package namespaces) such as
> "general", "message-delivery", "connection" etc. and these can have
> levels controlled independently. The default for "general" would be
> INFO (say) but for "message-delivery" it could be "error+".
>
> I think having a small set of categories is a good idea and one that
> would be nice to see in the Java world since the log level is hard to
> tweak without detailed knowledge of the code structure (effectively).
>
>   

You can do stuff like this (only enable debug+ for cluster for example)

--log-enable=debug+:cluster

regards
Carl.



> RG
>   

Re: [c++]: logging levels (was Re: C++ broker - some newbie questions)

[Robert Greig <ro...@gmail.com>]

2009/1/2 Gordon Sim <gs...@redhat.com>:

> At present for example a warning is logged for every published message that
> cannot be routed; every 'local' message dropped due to a 'no-local'
> directive results in an info level log message etc. As these are per-message
> events they could result in lots of log entries.

Yes, I can see this will be an issue.

Does your logging infrastructure have the concept of categories (like
log4j)? It may be useful to have a *small* set of categories (not like
log4j common usage which tends to map onto package namespaces) such as
"general", "message-delivery", "connection" etc. and these can have
levels controlled independently. The default for "general" would be
INFO (say) but for "message-delivery" it could be "error+".

I think having a small set of categories is a good idea and one that
would be nice to see in the Java world since the log level is hard to
tweak without detailed knowledge of the code structure (effectively).

RG

[c++]: logging levels (was Re: C++ broker - some newbie questions)

[Gordon Sim <gs...@redhat.com>]

Robert Greig wrote:
> 1) the broker's default output logging level is nothing. If you start
> it up, it gives no indication that it is doing anything at all. Is
> this deliberate? I think it should really be INFO level, or at least
> some level that enables the user to see that it is listening on a port
> without running netstat.

I agree that it would be nice to get a bit more information on startup.

The current default log level is set to error+ as info and warning were 
felt to be too verbose. To date the approach to adding log statements 
has been rather ad-hoc and really needs to be codified into a more 
explicit and useful system.

At present for example a warning is logged for every published message 
that cannot be routed; every 'local' message dropped due to a 'no-local' 
directive results in an info level log message etc. As these are 
per-message events they could result in lots of log entries.

We could alter those events to be logged only at the debug level, but 
they then become hard to see without further filtering as the output at 
debug level is extremely verbose. The logging system does allow control 
of levels by components but as it stands this does require a fair bit of 
knowledge of the codebase.

I don't have any clear answers yet but I do think we need to start 
thinking about more user friendly logging. Anyone else have any thoughts 
here?

Re: C++ broker - some newbie questions

[Robert Greig <ro...@gmail.com>]

2008/12/24 Steve Huston <sh...@riverace.com>:

> Windows broker auth will try to authenticate against local Windows
> accounts. For example, most of the examples/tests use user "guest" and
> password "guest" - you need to set up a "guest" account or else turn
> off auth (--auth no) or use a different user/password.

Thanks Steve, I should have tried local users.

I have added some text to the wiki to describe authentication for both
linux and Windows (very briefly).

RG

Re: C++ broker - some newbie questions

[Robert Greig <ro...@gmail.com>]

2008/12/24 Carl Trieloff <cc...@redhat.com>:

> Thus, it is possible to have config files that have options for additional
> modules that are not
> currently loaded (broker as configured does not know about), and in this
> case it is designed to
> ignore these extra options.

Presumably once it has completed loading all the modules it should
then be able to emit an error about unknown option(s)? I think that
the current behaviour would be a real pain for a support team. If you
happen to make a typo in the config file you won't find out very
quickly.

RG

Re: C++ broker - some newbie questions

[Carl Trieloff <cc...@redhat.com>]

Steve Huston wrote:
> Hi Robert,
>
> I've seen William's reply already...
>
>   
>> I have been using the C++ broker for the first time when doing some
>> testing of the WCF client. When doing this, I have made some
>> observations as a "new user":
>>     
>
> Great!
>
>   
>> 2) the broker does not complain when you give it an option that it
>> doesn't understand. For example:
>>
>> qpidbroker /eatmoremincepies
>>
>> doesn't yield any error or usage string. (After point 1, the curious
>> user may try to get help with the /help argument).
>>     
>
> Right... It uses the same option syntax as on Linux, --. Try
> qpidbroker --help
bit more detial - to get the options for optional module the module needs
to be loaded with the --help get it's options.

for example

qpidd --load-module acl.so --help

will add the section to the help for the acl module. A distr for example 
can set the module dir
and through all the modules in the module dir to be loaded by default.

Thus, it is possible to have config files that have options for 
additional modules that are not
currently loaded (broker as configured does not know about), and in this 
case it is designed to
ignore these extra options.

Carl.

RE: C++ broker - some newbie questions

[Steve Huston <sh...@riverace.com>]

Hi Robert,

I've seen William's reply already...

> I have been using the C++ broker for the first time when doing some
> testing of the WCF client. When doing this, I have made some
> observations as a "new user":

Great!

> 2) the broker does not complain when you give it an option that it
> doesn't understand. For example:
> 
> qpidbroker /eatmoremincepies
> 
> doesn't yield any error or usage string. (After point 1, the curious
> user may try to get help with the /help argument).

Right... It uses the same option syntax as on Linux, --. Try
qpidbroker --help

> 3) How do you configure authentication in the windows broker? The
info
> I read in one of the files in the distro didn't seem to apply for
> windows since it involved using a tool to create users. I had to
> disable authentication to get my client to run.

Windows broker auth will try to authenticate against local Windows
accounts. For example, most of the examples/tests use user "guest" and
password "guest" - you need to set up a "guest" account or else turn
off auth (--auth no) or use a different user/password.

-Steve