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 Wed, 30 Jul 2003 05:15:53 GMT
Noel J. Bergman wrote:
> One area still to be resolved is what to do with matcher/mailet messages.
> Sure, we can, and probably should, modify the MailetContext to add messages
> from matchers/mailets to the trace log, but unfortunately, the log() method
> does not support identifying the message, so how do we associate the log
> entry with the mail message?

Ok, now I understand your proposals.  I don't think I adequately
communicated the main technique used to do this message tracing.

What I very briefly mentioned in my first message is that we would use a 
ThreadLocal, which is how we identify messages.  Basically, scrap the 
whole notion of passing around the Mail object.  Ixnay on the 
essageTraceMay methods (sorry, pig latin will probably totally befuddled 
non-english speakers).

When you go process a Mail object, you stick the Mail object (or maybe 
just the ID) as a ThreadLocal attribute.  Then when you do the logging, 
you grab the mail/ID for your current thread, and that's how you know 
what message you're processing.  Every log(string) can now print 
"<message-id>: <date>: <logmessage>".

Also, you don't need to modify smtpserver as that sends the message via 
James.sendMail.  Basically these mods are all you need:
1. have the spooler set/remove the ID from a ThreadLocal
2. have the spooler log when it invokes a mailet (maybe support extra 
granularity, configured by the channel debug level)
3. have MailetContext.log() print the message ID to this new log channel 
(the one channel with keyed entries sounds fine)
4. have James.sendMail() log to this new channel AND if there is a 
message ID set in the thread local, then indicate the processing of that 
message ID is what caused the sending of this new message.

Like I said in (3), the single file with keyed lines works for me.  For 
the simple testing, that will just be one message so it's quite usable, 
and it will scale readily since you can use existing logging tricks.

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.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

View raw message