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

Cheers

Oleg

>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.
>
>Jandalf.
>
>
>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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to