hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [HttpAsync][log] How to implement logging?
Date Sat, 17 Jun 2006 17:01:28 GMT
Hi Oleg,

thanks for your feedback. Valuable indeed.

> There is no need for workarounds. In my experience a combination of the
> tread name and the class name are perfectly adequate for debugging the
> most heavy duty multithreaded applications. One can simply grep for a
> thread name and get a linear event flow for the given thread. 

1. We'll have different threads working on the same request/response.
   We would need at least some kind of request identifier to grep for.
2. I want to reduce the size of the log output. Consider one of those
   server applications that perform requests of some kind on behalf
   of different clients. I want to be able to enable logging only for
   specific requests/sessions/dispatchers.

> SimpleLog of Commons Logging does not support thread names but full
> fledged logging toolkits like Log4J usually do. I suspect you are
> tailoring your solution toward SimpleLog way too much.

I've never used SimpleLog at all, so I doubt I'm tailoring for it :-)
But I am indeed trying to avoid generating unwanted log output at all.
My background is RAS (WebSphere) and JLog 2.x, since these are what I
use at work.
For example, I am maintaining a code base where the same servlet code
is instantiated with different configuration settings multiple times
(say 20+) in a JVM. When the customer reports a problem with one of
those instances, I don't want combined log output from all of them.
And the customer doesn't want all instances to slow down because
logging is required for one of them. Unlike other ideas I occasionally
have, I believe this is a very real requirement we need to address.

> I am afraid you are going a little overboard with this. Unless I am
> missing something that implies a context lookup operation per class,
> which sort of goes counter to the idea of logging having zero (or next
> to zero) impact on application performance when logging is off (or set
> to ERROR priority). I remain skeptical for now but do feel free to take
> a stab at it and see how it turns out in code.

It implies context lookups per request, that is true. I'll think it
over again with performance in mind. Thanks for pointing it out.
Storing the request specific log object in the handle should avoid
most of the overhead for request specific logging. Dispatchers can
also do a single lookup when they're created, or when they are told
that the context settings might have changed.


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

View raw message