james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Message path tracing
Date Tue, 29 Jul 2003 20:46:17 GMT
Noel J. Bergman wrote:
> My first inclination is that Serge has the right idea, but possibly the
> wrong solution to the problem.  Having per-message logs (Msg#.log) won't
> scale, and I believe that problems arise other than in someone's controlled
> test environment as they develop their pipeline logic.

Good point.

> It seems to me, and there is also a bugzilla entry that relates to this,
> that we should audit all of our message related log formats to make sure
> that the content is parsable and has all of the necessary information to
> associate log messages with mail messages, and then provide a log analyzer.

I may be forgetting, but I'm pretty sure this relates only to using 
something like webalizer to analyze sendmail-style logs, so as I put it, 
the SMTP-stuff.

> A hypothetical pipeline analyzer could merge the various existing logs, sort
> them by message key, and then filter out events by the message(s) we're
> interested in following.

While this could help isolate an odd production bug, I think it fails 
for users trying to learn James and actively debug mailets or matchers.

> Serge has made a point that logs for smtp traffic analysis and logs for
> pipeline debugging might have different content/formats.  Possibly so, but I
> don't believe that precludes using a log analyzer.

I understand a log analyzer for smtp traffic (like webalizer).  Unless 
you're talking about some GUI analysis of some after-the-fact logging 
(which I don't even like that much), I don't see much value.  Sure, it's 
better than what we have, but that says little.

> Either way, we have to go through SMTP handler, the pipeline, into matchers
> and mailets (at least in my opinion), and the POP3 handler, and make some
> logging changes.  At the minimum, it would seem to me that want to log

This mailet & matcher log changes... I was just talking of adding the 
message info in the logs.  Adding message info in the logs is doable 
without touching the implementations, and in all but lifecycle 
situations, the log messages have a message associated with them and 
could in most cases benefit from that info.

This is an important point to me because it determines whether we add 
code in 3 places, or 18 + every custom mailet & matcher people use.

> I believe that Serge's idea is that we would instrument the SMTP handler
> (probably also any similar message source, such as FetchMail), the spooler,
> and the log operation(s) in the MailetContext.  We would have some redundant
> logging code, but hopefully could keep it to a minimum.  I'm not sure how
> this per-message log would tie into the Avalon code, but that's TBD if we go
> this route.

I don't see how Avalon code relates to what we're talking about.  What 
code is redundant?

> Personally, I prefer the log analyzer approach for a few reasons:
> 
>   - logs for the log analyzer could be left on with
>     some degree of verbosity
What's the benefit or objective?  We already have debug/info/etc... 
control over level of verbosity, but it's still very difficult to track 
and goes beyond sending messages to different streams.

>   - the per-message log mechanism would rapidly create
>     too many directory entries for many platforms.
Yes, it's not scalable, which is the one outstanding issue.

>   - no redundant code
What is redundant?  You seem to be critiquing the way you would 
implement this...

>   - resolves bugzilla
This is unrelated, IMHO.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message