chainsaw also makes it easy to split a log into separate threads... as well as
providing lots of other useful features!
http://logging.apache.org/log4j/docs/chainsaw.html
cheers,
Stephen
James Stauffer
<[EMAIL PROTECTED] To: "'Log4J Users List'" <[EMAIL
PROTECTED]>
erce.com> cc:
Subject: RE: One file for every thread
15/07/2004 15:49
Please respond to
"Log4J Users
List"
If you logged to a database it would be easy to select the logs from one
thread.
-----Original Message-----
From: DE BENEDICTIS DAVIDE [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 9:46 AM
To: Log4J Users List
Subject: RE: One file for every thread
> -----Original Message-----
> From: Glenn Strickland [mailto:[EMAIL PROTECTED]
>
> I think the suggested way of dealing with a multi-threaded
> server is not to log each threads output to a separate file,
> but to tag each log record with an identifier unique to that
> thread, then log them to the same file.
I was reading Ceki Gülcü's reply to the same question from another user
here:
http://www.slimmit.com/go.asp?2SF
He was trying to understand a use case for this feature. Now, without going
into an indepth description of my app, I agree that NCD and MCD are the best
options in a web or J2EE environment: in these apps usally threads are
managed entirely form the application server that can dinamically spawn a
large number of them to fulfill application requests. Usually a programmer
and his application are not thread aware and so a "per thread" logging
facility wouldn't be useful at all being nearly impossible to map a thread
with a client or tx.
But imagine you have a proprietary server application in which the number of
threads (application processes) creation is well defined and maybe fixed.
Furthermore a particular thread is specialized since app starts executing a
single task. In this case is easy mapping one tx with one thread and so
could be useful having this feature.
Foe example, I could have a POJO server application with five threads
running. Each thread has a different instance of a set of objects selling
cinema tickets on a db.
It's useful just opening one logging file and follow one ticket transaction
line by line without having concurrent ticket tx mixed all together.
Yes I could do something like:
cut -d '[' -f3 tickets.log | cut -d ']' -f1 |
uniq | awk '{system("grep -e " $1 " *.log > log"$1 ".txt")}'
Having diffent files with different threads logging...
But why not something inside my logging facility? ;-))
I hope now I was a little bit clear.
Thank you for the patience.
--
Davide
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
