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