james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Message path tracing
Date Tue, 29 Jul 2003 21:30:06 GMT
With respect to the existing bugzilla report, the one I had in mind in my
earlier message was:

> While [the log analyzer] could help isolate an odd production bug, I think
> fails for users trying to learn James and actively debug mailets or


> 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.

Actually, that is very much what I had in mind.  A browser that would show
the messages, and the pipeline flow that happened to them from inception to

> This mailet & matcher log changes... I was just talking of adding the
> message info in the logs.

Sorry, I meant to correct that comment in my note.  I fixed it in one place,
and missed it in the other.  The mailet logging is isolated to the
MailetContext implementation, so it does not require changing anything that
uses the Mailet API to do logging.

> 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.

That's my concern, too.  :-)  I don't want to see the latter, either.

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

Avalon provides the logging framework, and hands the logging component to
each service.  If we are going to log to the component log and the
per-message log, (a) how does a component access the latter, and (b) each
getLogger().LEVEL(...) message that relates to per-message processing
becomes duplicated: one of the normal log, the other for this per-message

> 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.

Steven Short suggested that some people might prefer to have all of the
messages sequential in a single log.  On the other hand, that doesn't
highlight the sequence that happens to a single message if that processing
is interleaved with other things over a wide amount of time.

> You seem to be critiquing the way you would implement this...

Always.  :-)

I want to make debugging easier for people.  I am rather tired of
monotonously typing "Turn on DEBUG for the spool manager log.  You will be
able to trace the details of each step the message took through the
pipeline" daily.  I think that has been the #1 FAQ in recent months.  I'm
just not sure how best to make debugging easier, and am mulling over out
loud the implications of the approach(es).

	--- Noel

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

View raw message