Hi Carl,
Thanks for the patch.
From looking at your chanegs and going over options in my head it may
be difficult to handle these two cases at the same time. The two cases
being 1) max connections per host and 2) max total connections. I am
going to look at your patch some more. At the
Mike,
I like the idea of a cap on the total number of connections as a
configurable default.
Perhaps HttpClient doesn't need to implicitly perform connection
recycling on idle connections, but how about adding an explicit method
on MultiThreadedConnectionManager that clients can call -
First, let me say that finding HttpClient was this week's bacon-saver. The
other alternatives out there are, shall we say politely, a bit lacking.
I have, however, run into a couple of things. Apologies if these have been
covered before. I tried searching the archives, and found some close
Carl,
That's OK, the problem
I run into is that after running for not very long, I suddenly start
getting
everything timing out. It's hard to really pinpoint the timing, giving all
the
activity, and no thread identifiers in the log messages, but I think what
is
happening is that the
On Thursday March 20 2003 17:43, Oleg Kalnichevski wrote:
Carl
First of all, many thanks for bringing these issues up
No problem. It's nice to see such positive and quick reponses!
I can provide example URLs, if this will help.
Please do so. It will help me testing
BTW, here is a quick patch to degrade the code to work with these types of
messages:
*** HttpParser.java~Tue Feb 25 10:22:00 2003
--- HttpParser.java Thu Mar 20 02:06:02 2003
***
*** 53,61
break;
}
buf.write(ch);
Hi Adrian,
OK, that sounds like a good approach. I'll play around with something and post
it back here if I get it to work for my use. Perhaps I can tweak
MultiThreadedHttpConnectionManager to take a parameter that caps the overall
pool size.
On Thursday March 20 2003 17:52, Adrian Sutton
