Re: formal debug levels

> On Fri, 2007-10-26 at 10:01 +1300, Amos Jeffries wrote:
>> >> >
>> >> > 0 - Should not ever happen; requires administrator action
>> >> > 1 - Happens once per Squid execution or requests administrator
>> >> attention
>> >> > 2 - Happens once in a while, unrelated to load
>> >> > 3 - Happens once per transaction
>> >> > 4 - ... and dumps a lot of data (e.g., request headers)
>>
>> I considered these 'dumps a lot of data' levels earlier and decided they
>> would be better going in the higher levels if there were to be included
>> at
>> all.
>> If anyone wants to debug say a function at your level 5 or 7. They do
>> not
>> exactly want to wade through the full-dump of request header buffers or
>> other objects to find it.
>
> I think the best approach is to make "dumps a lot of data" a flag that
> does not depend on the level. The admin will decide whether they want
> the data or not.

Yes I agree with that.

>
>> >> > 5 - Happens once per I/O or similar regular activity inside
>> >> transaction
>> >> > 6 - ... and dumps a lot of data
>> >> > 7 - Happens several times per I/O or similar (e.g., parsing a
>> token)
>> >> > 8 - ... and dumps a lot of data
>> >> > 9 - Happens a lot, duplicates information, or may not be very
>> useful
>
>> Do you mean each of the current components would become an AsyncJob?
>> Great :-) I was wondering at the goal of these recent async commits
>
> Everything that looks like an asynchronous task, job, logical thread,
> etc, will have a chance to become AsyncJob child, get rid of wrappers,
> improve debugging, and protect itself from assertions.
>
>> >> > This may simplify context and
>> >> > section management a lot because you would not need to do it in
>> every
>> >> > method. For example, most "entering..." and "exiting..." debugging
>> >> > statements will be gone (moved to a single place).
>>
>> That may not be such a good idea for the per-function ones.
>> having said that, I'm experimenting with details displayed by the HERE
>> macro which may replace function-specifics.
>
> The default debugging is for each async call, not each function. It
> includes job state and may even include call arguments. ICAP uses a
> prototype of that approach, and I like it a lot. YMMV.

I'm a little unsure what you are defining as a 'call' here.
You mean a full event loop? or just a class method/API call and everything
it references to do its job?

Either way after AsyncJob, I think that would add another debug level by
itself (job/event/thread start/stop) between component start/stop and
function start/stop.

Amos
Received on Thu Oct 25 2007 - 18:42:01 MDT