hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <o.kalnichev...@dplanet.ch>
Subject Re: [PATCH] Wire logging revised (attempt 2)
Date Wed, 26 Feb 2003 13:37:21 GMT
Folks
Any feedback on this one. Can interpret absence of responses as silent
approval ;-)
Cheers
Oleg  


On Mon, 2003-02-24 at 14:02, Oleg Kalnichevski wrote:
> I hope it works this time around
> 
> Oleg
> 
> 
> On Thu, 2003-02-13 at 07:30, Jeffrey Dever wrote:
> > 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> > 
> 
> ______________________________________________________________________
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message