Hi Oleg, > > > Feasible approach is to have one monitor thread checking on the status > > > of active connections or/and processing incoming connections, and a > > > number of worker threads in a shared pool to do the actual work. > > > > Actually since probably most people using httpclient with many > > connections would need that, would it make sense to have it > > shared somewhere, for example in httpclient? > > I assume you are developing some kind of HTTP proxy, since you have > HttpClient running inside a servlet container. While not being entirely
Well, no, not an HTTP proxy :). I will save you a visit at www.mnc.ch, we're processing SMS/MMS between operators and content providers. > impossible (I have one serving a population of a large Swiss canton), > HttpClient 2.x and 3.x have not been specifically designed to be used in > such a manner. My guts tell me that it might involve quite a few nasty > hacks if to be made truly generic and reusable. In my option it is just > not worth the trouble and will not bear results generic enough to be > useful in most of scenarios. I see. > We are planning to embark on a fundamental redesign of HttpClient in a > not so distant future (past 3.0b1 I'd say). Our intent is to turn > HttpClient into a generic HTTP toolkit which can be used to rapidly > assemble HTTP agents, proxies or embedded lightweight servers. > > At that point we will probably seriously consider using NIO and provide > some sort of thread management/connection management classes or use an > external library for that end. Ok, thank you for the information. > But first things first, and one thing at a time > > > commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#setTimeout(int) > > > > > > Yes, we're already using that (and connection timeouts as well). > > We're just in trouble when the post never finishes, but actually > > the server is very slow (if it sends one byte per second for > > example, but on a regular basis) or goes mad. > > Basically what you are talking about is ability to abort execution of > HTTP methods. Consider using HttpClient 3.0a2 which provides such > capability. You'll have to add a little code to handle timing of method > execution, which should not be that difficult Ok, thanks. I haven't look far in 2.0 but I was fearing that releaseConnection was not really appropriate for aborting a method in middle of execution. It was even maybe synchronized so it might just have blocked another Thread :). Thanks again for your prompt and insightful answers. -- Guillaume Cottenceau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
