hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <o.kalnichev...@dplanet.ch>
Subject [PATCH]: Wire logging revised (attempt 2)
Date Mon, 24 Feb 2003 11:04:03 GMT
Another attempt at cleaning up wire logging in HttpClient based on Jandalf's and Mike's input.

I can't say the solution is perfect, but it'd like to hope it'd be a step forward compared
to what we have today



>Haven't had time to review all of this, but I am a bit concerned over 
>any performance issues and buffering.  The wirelog is a good thing, but 
>there are other ways of getting a request/response log.  I wouldnot like 
>to see it excessively effect performance or resident set size, or add 
>too much complexity.
>Also I find that the wirelog output conforms to the 10%/90% rule where 
>90% of its troubleshooting value comes from 10% of its output, namely 
>the headers and request/response status lines.  The applications I have 
>written based on HttpClient would never enable the wirelog because the 
>output was too large (and could contain offensive binary data), so I 
>would just never enable it and use the applications logging system and 
>my own methods to write out the headers.  This should be a better 
>service provided by HttpClient.
>We could just read/buffer/process/log headers in one shot in one logger, 
>and handle the body logging seperately.  The header logs might be part 
>of the normal operation of some applications where the body log would 
>only be used for headscratching debugging.  That might help a little bit 
>with the seperation of concerns that we are grappling here.
>Michael Becke wrote:
>> Well after looking at this further it seems one problem with this is 
>> that bytes get written one at a time to the input WireLog.  I made a 
>> few changes in HttpConnection and WireLogInputStream that pose a 
>> possible solution.  This version of the InputStream buffers content 
>> until a "\r\n" is read or until a certain number of bytes are read.  
>> This way wire log will always work even if content is read using the 
>> socket input stream.  Take a look.  These are just some other ideas.
>> Mike
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message