hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: [PATCH] MultipartPost revisited (take 2) ATTN: Mike Becke
Date Thu, 13 Feb 2003 06:30:57 GMT
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

View raw message