> 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, ho
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
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
Htt
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
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
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 ('cep
