Oleg,
ContentLengthInputStream extend java.io.FilterInputStream, which
supports mark and reset. However, ContentLengthInputStream does not keep
track of when these are called and appropriately adjust the current
posistion. It keeps incrementing the counter on each read() without
decrementing it on reset(). So basically we just added support for these
two methods. Please note that this quick fix does not check to see if
somebody reads past the mark readlimit, etc.
Thanks,
Bjarne.
56a57,58
> private int markpos = 0;
> private boolean inmark = false;
107a110
> if (inmark) markpos ++;
110a114,127
> public void mark(int readlimit) {
> super.mark(readlimit);
> inmark = true;
> markpos = 0;
> }
>
> public void reset() throws IOException {
> inmark = false;
> super.reset();
> pos = pos - markpos;
> markpos = 0;
> }
>
>
135a153
> if (inmark) markpos += count;
169a188
> if (inmark) markpos += length;
>>> [EMAIL PROTECTED] 09/29/04 4:06 PM >>>
Bjarne,
Can you send the a patch (diff -u) against HTTPCLIENT_2_0 branch or just
a snippet of the offending code? It will help me avoid manual comparison
of two files
Oleg
On Wed, 2004-09-29 at 21:33, Bjarne Rasmussen wrote:
> We've tried out the nightly and think there may be an issue in the
> mark/reset code of
> org.apache.commons.httpclient.ContentLengthInputStream.java (please
see
> attached for rudimentary fix). With this fix performance and
> functionality is great.
>
> Thanks,
> Bjarne.
>
> >>> [EMAIL PROTECTED] 9/28/2004 11:52:56 AM >>>
> Great news indeed. The reported performance boost does justify cutting
> a
> new release. Folks, how do you all feel about releasing HttpClient
> 2.0.2?
>
> Oleg
>
> On Tue, 2004-09-28 at 00:38, Eric Johnson wrote:
> > And I've finally gotten test results back from the appropriate
people
> here.
> >
> > In our test lab, between HttpClient 2.0.1 and the nightly, we found
a
>
> > difference of about 4ms per request. As this was a live-test
> > environment, with all of our application environment around
> HttpClient,
> > the total numbers are probably mostly irrelevant to HttpClient, but
> the
> > measurable improvement was entirely due to HttpClient changes.
> >
> > We have some other statistics, but I worry that those are misleading
> for
> > now, so I'm not mentioning those. Hopefully, I'll be able to pass
> along
> > some concrete data at some point.
> >
> > For our purposes, the build otherwise looks stable.
> >
> > -Eric.
> >
> > Oleg Kalnichevski wrote:
> >
> > >Folks,
> > >
> > >Could you please grab the latest 2.0 nightly build and see if it
> runs
> > >stable enough for production purposes? When we have a couple of
> reports
> > >confirming adequate stability, we'll call for the 2.0.2 release
> > >
> > >Oleg
> > >
> > >
> > >On Fri, 2004-09-03 at 00:00, Eric Johnson wrote:
> > >
> > >
> > >>My read on Odi's statistics is that the patch has a pretty
> consistent
> > >>1ms impact on every request. This corresponds pretty well with my
>
> > >>understanding of the theoretical improvements behind the patch.
To
> the
> > >>effect that HttpClient's performance is affected, header parsing
> will be
> > >>faster, and reading the body of the connection will be roughly the
> same,
> > >>presumably because the client of HttpClient buffers large reads.
> > >>
> > >>On a 1Ghz machine, this patch means one million processor cycles
> that
> > >>can be put to a better use for *each* request. That's more than
> > >>benchmark optimization, I think.
> > >>
> > >>-Eric.
> > >>
> > >>Oleg Kalnichevski wrote:
> > >>
> > >>
> > >>
> > >>>Eric,
> > >>>
> > >>>This patch makes a difference for only relatively small payloads
> when
> > >>>the response content is about the size of the status line +
> headers. In
> > >>>most (real life) cases the performance gain is virtually
> negligible.
> > >>>This is more about benchmark optimization than anything else.
> > >>>
> > >>>Yet, it see no problem with another point release
> > >>>
> > >>>Oleg
> > >>>
> > >>>On Thu, 2004-09-02 at 19:06, Eric Johnson wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>I don't know whether this would be a premature time to call for
a
> new
> > >>>>release, but the prospect of significantly better performance
out
> of
> > >>>>HttpClient has some people in my company very interested.
> > >>>>
> > >>>>What are the chances of a 2.0.2 release with this fix in it?
> (I'm
> > >>>>willing to build from the source, but others in my company like
> the idea
> > >>>>of an "official" build perhaps more than they need to.)
> > >>>>
> > >>>>-Eric.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
>
>>---------------------------------------------------------------------
> > >>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]
> >
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
