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: The Logging Non-Problem
Date Sun, 05 Mar 2006 17:36:59 GMT
Hi Oleg,

> Low level components such as http-core, http-nio, http-auth and, imo,
> http-async must throw exceptions and never log messages either directly
> to stdout or via a logging toolkit.

In http-async, I have background threads switching states and (beginning
in March) performing callbacks to application code. The operations of
these threads can not be logged appropriately by http-client. Throwing
exceptions is also pointless in background threads. Besides, I can't
throw an exception in case of a deadlock or similar misbehavior.

Connection management is another example where I would hope for logging
information about the internal state of the managed data. Though that can
probably be addressed by providing specific toString() or similar methods,
to be called from http-client and/or http-async. Or else not, considering
that the thread supposed to log can be blocked when allocating a connection.
I'm not sure about http-auth for stateful or connection based authentication.

> We must not impose a specific
> logging toolkit on the users of these components.

commons-logging is a wrapper for an arbitrary logging toolkit. The one
time I had to integrate HttpClient into an application, I was quite happy
with it. No big problem to write an adapter, to JLog 2.x in that case.

> Logging per ce does not solve any problem. I regularly spend quite a bit
> of my time analyzing huge log files when trying to help people
> troubleshoot their problems with HttpClient. I usually find 99% of the
> context log entries completely useless. Usually only HTTP headers are of
> any use. Moreover, 90% of problems are caused by cookie or
> authentication headers. A tiny fraction of the time I have spent these
> years on grepping through all those wire logs could have been spent on
> writing a tutorial on how to enhance HttpClient bytecode to log just
> specific type of information.

Fair concern. I agree that the overwhelming share of the problems we
see can be handled with a wire log and/or information about the headers.
But I have to prepare for a different kind of problems in http-async.

Bytecode fuddling is something I don't want to get into. I haven't
written assembler code since my diploma thesis, and bytecode manipulation
is close to that level :-) The advantage of log statements in the code is
that you don't have to put them there when problems show up. But given
the interactive nature of the support we're giving, that may indeed be
the better options.
I'm used to a different kind of troubleshooting at work. When I am sent
to a customer, they usually have a huge chunk of complex products
installed, and I need to track down something without knowing where
exactly the problem comes from. Playing with the bytecode is out of the
question, and even adding debug code to the systems is usually a problem.
So I enable logging of some components about which I am suspicious, and
hope that the developers didn't forget to put in the one log statement
that would help me.

> I think we should eat our own dog food. Besides, there is a lot of
> activity going out around commons [logging] these days. There are
> indications many sound concepts originating from UGLI will get
> incorporated into commons [logging]

OK, commons-logging it is. That's my preference too.

>>I intend to have another programming stint on http-async next weekend and
>>a few days of the week after. I hope for feedback on the logging questions
>>until then. If we come to a common understanding, and if time permits,
>>I would like to make http-async the pilot for all our components that are
>>going to use logging. But considering the effort it would take, I don't
>>want to rush ahead and implement something that will not be accepted as
>>the basis for other HTTP components.

Assuming that only http-client and http-async will use logging,
I'll forget about preprocessing and compiling different versions.


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

View raw message