You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2004/07/03 00:06:48 UTC
Re: questionable default value for BufferedOutputStream size in
HttpConnection and memory usage?
Hi Eric
Thanks for bringing this up. HttpClient 3.0 allows for parameterization
of SO_SNDBUF and SO_RCVBUF settings. For HttpClient 2.0 (as well as for
3.0 when falling back onto the system defaults), however, it would make
sense to set a cap on the size of the send and receive buffers.
Feel free to open a ticket for this issue with Bugzilla
Oleg
On Fri, 2004-07-02 at 18:39, Eric Bloch wrote:
> Hi httpclient folks,
>
> I've been looking at 2.0 source code and the default value for the
> BufferedOutputStream that is used in an HttpConnectionn is coming from
> socket.getSendBufferSize(). My hunch, is that, in general, this is
> bigger than you'd want.
>
> Most HTTP "sends" are less than 1KByte ('cept for big POSTs).
> The default value I get for socket.getSendBufferSize for this is 8192.
> I would think a better default for this buffer would be 1K, no?
>
> Also, fyi, if someone happens to dork the system send buffer size hi
> (say MB) and you are using the MultiThreadedConnectionManager in 2.0
> (dunno about 3.0), you will use up a lot of memory for each connection
> since the pool doesn't let idle connections (or their buffers) be gced.
> I just got bit bad by that.
>
> -Eric
>
>
> ---------------------------------------------------------------------
> 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
Re: questionable default value for BufferedOutputStream
size in HttpConnection and memory usage?
Posted by Oleg Kalnichevski <ol...@apache.org>.
> Next time I have the cycles to sit down with JMX *and* port Laszlo's
> product from httpclient 2.0 to httpclient 3.0, I may be able to get to
> this :-). I'd be focused on settings for a client using the
> MultiThreadedConnectionManager.
That should be a very welcome contribution
>
> Btw, how do I go about getting the Laszlo Presentation Server listed on
> the applications page for httpclient? We've been a user since 1.0
> actually.
Currently one just needs to apply.
> We use httpclient as the core HTTP transport for a
> transcoding proxy inside the Laszlo Presentation Server. See
> http://www.laszlosystems.com/ for all sorts of details including free
> developer and non-commericial-use downloads and documentation. As to a
> short blurb for the 'applications page', something like:
>
I'll add an entry for Laszlo Presentation Server with the description
given below to the application page sometime later this week
> The Laszlo Presentation Server is an XML-native platform for the
> development and delivery of a new generation of Rich Internet
> Applications. For a quick introduction see:
> http://www.laszlosystems.com/lps/laszlo-in-ten-minutes/ .
>
> Btw, we also have an interest in using httpclient as the transport for a
> SOAP client if anyone else is working on that.
>
Apache Axis can use HttpClient as a transport agent of choice. Check it
out at
http://ws.apache.org/axis/
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: questionable default value for BufferedOutputStream size in HttpConnection
and memory usage?
Posted by Eric Bloch <bl...@laszlosystems.com>.
>
> JMX has not been formally considered or discussed on this list. I
> personally do not think it would have made a good match
>
> HttpClient needs to allow for customization of lots of short-lived
> objects (HttpMethods, HostConfigurations, HttpConnections, etc), whereas
> JMS is better suited for relatively few long-lived objects that usually
> represent some type of services (at least IHMO). JMX would be simply too
> much, too heavy-weight. For HttpClient's needs light-weight linked
> hash-maps do just fine.
>
> This said, an JMX layer sitting on top of HttpClient that provide MBeans
> for HttpClient instances would be a great contribution
>
>
Hey Oleg,
Next time I have the cycles to sit down with JMX *and* port Laszlo's
product from httpclient 2.0 to httpclient 3.0, I may be able to get to
this :-). I'd be focused on settings for a client using the
MultiThreadedConnectionManager.
Btw, how do I go about getting the Laszlo Presentation Server listed on
the applications page for httpclient? We've been a user since 1.0
actually. We use httpclient as the core HTTP transport for a
transcoding proxy inside the Laszlo Presentation Server. See
http://www.laszlosystems.com/ for all sorts of details including free
developer and non-commericial-use downloads and documentation. As to a
short blurb for the 'applications page', something like:
The Laszlo Presentation Server is an XML-native platform for the
development and delivery of a new generation of Rich Internet
Applications. For a quick introduction see:
http://www.laszlosystems.com/lps/laszlo-in-ten-minutes/ .
Btw, we also have an interest in using httpclient as the transport for a
SOAP client if anyone else is working on that.
Best,
-Eric Bloch
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: questionable default value for BufferedOutputStream size
in HttpConnection and memory usage?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2004-07-03 at 02:26, Eric Bloch wrote:
> Thanks, I filed against 2.0 final. A question: did you guys consider
> jmx for your 'preferences architecture' ?
Eric,
JMX has not been formally considered or discussed on this list. I
personally do not think it would have made a good match
HttpClient needs to allow for customization of lots of short-lived
objects (HttpMethods, HostConfigurations, HttpConnections, etc), whereas
JMS is better suited for relatively few long-lived objects that usually
represent some type of services (at least IHMO). JMX would be simply too
much, too heavy-weight. For HttpClient's needs light-weight linked
hash-maps do just fine.
This said, an JMX layer sitting on top of HttpClient that provide MBeans
for HttpClient instances would be a great contribution
Oleg
>
> Thanks,
> Eric
>
>
> Oleg Kalnichevski wrote:
>
> > Hi Eric
> >
> > Thanks for bringing this up. HttpClient 3.0 allows for parameterization
> > of SO_SNDBUF and SO_RCVBUF settings. For HttpClient 2.0 (as well as for
> > 3.0 when falling back onto the system defaults), however, it would make
> > sense to set a cap on the size of the send and receive buffers.
> >
> > Feel free to open a ticket for this issue with Bugzilla
> >
> > Oleg
> >
> >
> > On Fri, 2004-07-02 at 18:39, Eric Bloch wrote:
> >
> >>Hi httpclient folks,
> >>
> >>I've been looking at 2.0 source code and the default value for the
> >>BufferedOutputStream that is used in an HttpConnectionn is coming from
> >>socket.getSendBufferSize(). My hunch, is that, in general, this is
> >>bigger than you'd want.
> >>
> >>Most HTTP "sends" are less than 1KByte ('cept for big POSTs).
> >>The default value I get for socket.getSendBufferSize for this is 8192.
> >>I would think a better default for this buffer would be 1K, no?
> >>
> >>Also, fyi, if someone happens to dork the system send buffer size hi
> >>(say MB) and you are using the MultiThreadedConnectionManager in 2.0
> >>(dunno about 3.0), you will use up a lot of memory for each connection
> >>since the pool doesn't let idle connections (or their buffers) be gced.
> >> I just got bit bad by that.
> >>
> >>-Eric
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: questionable default value for BufferedOutputStream size in HttpConnection
and memory usage?
Posted by Eric Bloch <bl...@laszlosystems.com>.
Thanks, I filed against 2.0 final. A question: did you guys consider
jmx for your 'preferences architecture' ?
Thanks,
Eric
Oleg Kalnichevski wrote:
> Hi Eric
>
> Thanks for bringing this up. HttpClient 3.0 allows for parameterization
> of SO_SNDBUF and SO_RCVBUF settings. For HttpClient 2.0 (as well as for
> 3.0 when falling back onto the system defaults), however, it would make
> sense to set a cap on the size of the send and receive buffers.
>
> Feel free to open a ticket for this issue with Bugzilla
>
> Oleg
>
>
> On Fri, 2004-07-02 at 18:39, Eric Bloch wrote:
>
>>Hi httpclient folks,
>>
>>I've been looking at 2.0 source code and the default value for the
>>BufferedOutputStream that is used in an HttpConnectionn is coming from
>>socket.getSendBufferSize(). My hunch, is that, in general, this is
>>bigger than you'd want.
>>
>>Most HTTP "sends" are less than 1KByte ('cept for big POSTs).
>>The default value I get for socket.getSendBufferSize for this is 8192.
>>I would think a better default for this buffer would be 1K, no?
>>
>>Also, fyi, if someone happens to dork the system send buffer size hi
>>(say MB) and you are using the MultiThreadedConnectionManager in 2.0
>>(dunno about 3.0), you will use up a lot of memory for each connection
>>since the pool doesn't let idle connections (or their buffers) be gced.
>> I just got bit bad by that.
>>
>>-Eric
>>
>>
>>---------------------------------------------------------------------
>>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
--
Laszlo Systems, Inc.
1040 Mariposa Street, SF, CA, USA 94107
voice: 415.241.2721
fax: 415.865.2914
im: eedeebee at yim; eedeebee3 at aim
email: bloch@laszlosystems.com
--
Laszlo allows Behr to deliver a breakthrough experience with
ColorSmart by BEHR application at http://www.behr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org