You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Guillaume Cottenceau <gc...@mnc.ch> on 2004/10/01 12:57:46 UTC
threads problem with many connections
Hello,
We use HttpClient for performing several HTTP post in parallel in
our applications. We have a problem when the server(s) receiving
our HTTP post either answers very slowly, or goes mad and sends
garbage data over and over: the connection stays open forever,
but more important, the Java threads as well. We have situations
where we reach the maximum of Java threads our (tomcat)
application is configured to handle, and our whole application is
then unusable.
It seems that java.nio is capable of using only one thread for
several lowlevel (OS) socket connections, and is actually also
quite efficient.
I have seen that Oleg Kalnichevski has already expressed his
views several times on the subject, and I have seen that you want
to keep 1.2 compatibility, so java.nio out.
http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg05551.html
http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg06998.html
(btw, I don't agree with "in my opinion there's absolutely
nothing that NIO can bring in in terms of performance to
client-side applications" - well I agree that pure "performance"
is not the problem but threads and memory consumption surely is -
so in my opinion there is a lot to win with java.nio in
httpclient)
My question is, since you don't want to lose 1.2 compatibility
before 4.0, is there then a way to solve a typical "too many
threads" problem such as the one we have? Do you people never had
the same problem? Or have found a way to solve it?
It seems the HTTP protocol doesn't have anything resembling a
"global timeout" for a given connection (e.g. after x seconds,
close the receiving channel even if server hasn't finished
sending), and thus normally httpclient doesn't provide such a
thing. Do you think this should be investigated/implemented in
some way?
Thanks, and best regards.
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Oleg Kalnichevski <ol...@bearingpoint.com>.
> > 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
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.
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.
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
Oleg
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Oleg,
Thanks for your answer.
> > It seems that java.nio is capable of using only one thread for
> > several lowlevel (OS) socket connections, and is actually also
> > quite efficient.
>
> Guillaume,
>
> Please correct me if my understanding of the problem is incorrect, it is
> Tomcat that runs out of connections, not HttpClient. In fact, there's
> only one case when HttpClient spawns a new thread, and if so is desired,
> this can be disabled. The thread management is entirely responsibility
> of your application. One does not have to use one thread per socket
> model even without NIO.
Yes, you're right. Our application is running out of threads,
e.g. Tomcat actually, not HttpClient. Sorry for not being clear
about that.
My understanding of java.nio with multiple IO connections managed
by a single java Thread (this is probable what you call
multiplexing in your previous message?), is that we could imagine
using an asynchronous executeMethod-like that would initiate a
connection in a unique httpclient Thread dealing with all the
connections, returning back immediately, and later a callback be
invoked when data is available (in httpclient situation, the
callback at the "user" level (the program using httpclient) could
be called upon completion of request).
This way, one tomcat thread could be performing several HTTP
posts itself.
In real-life, it doesn't solve all of our problems because we
have some HTTP posts that need to be executed after completion of
others.
> > My question is, since you don't want to lose 1.2 compatibility
> > before 4.0, is there then a way to solve a typical "too many
> > threads" problem such as the one we have? Do you people never had
> > the same problem? Or have found a way to solve it?
>
> 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?
> > It seems the HTTP protocol doesn't have anything resembling a
> > "global timeout" for a given connection (e.g. after x seconds,
> > close the receiving channel even if server hasn't finished
> > sending), and thus normally httpclient doesn't provide such a
> > thing. Do you think this should be investigated/implemented in
> > some way?
>
> I do not recall HTTP protocol as such dealing with timeouts in any way.
> I may be wrong, though. This is certainly not a protocol concern.
> HttpClient does provide so called socket timeout. When set to a positive
> number, the connection will terminate with an IOException after the
> specified period of inactivity:
>
> http://jakarta.apache.org/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.
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Oleg Kalnichevski <ol...@bearingpoint.com>.
On Fri, 2004-10-01 at 12:57, Guillaume Cottenceau wrote:
> Hello,
>
> We use HttpClient for performing several HTTP post in parallel in
> our applications. We have a problem when the server(s) receiving
> our HTTP post either answers very slowly, or goes mad and sends
> garbage data over and over: the connection stays open forever,
> but more important, the Java threads as well. We have situations
> where we reach the maximum of Java threads our (tomcat)
> application is configured to handle, and our whole application is
> then unusable.
>
> It seems that java.nio is capable of using only one thread for
> several lowlevel (OS) socket connections, and is actually also
> quite efficient.
Guillaume,
Please correct me if my understanding of the problem is incorrect, it is
Tomcat that runs out of connections, not HttpClient. In fact, there's
only one case when HttpClient spawns a new thread, and if so is desired,
this can be disabled. The thread management is entirely responsibility
of your application. One does not have to use one thread per socket
model even without NIO
>
> I have seen that Oleg Kalnichevski has already expressed his
> views several times on the subject, and I have seen that you want
> to keep 1.2 compatibility, so java.nio out.
>
> http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg05551.html
> http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg06998.html
>
> (btw, I don't agree with "in my opinion there's absolutely
> nothing that NIO can bring in in terms of performance to
> client-side applications" - well I agree that pure "performance"
> is not the problem but threads and memory consumption surely is -
> so in my opinion there is a lot to win with java.nio in
> httpclient)
>
I have done quite a bit of NIO programming lately and respectfully stick
to my original opinion.
> My question is, since you don't want to lose 1.2 compatibility
> before 4.0, is there then a way to solve a typical "too many
> threads" problem such as the one we have? Do you people never had
> the same problem? Or have found a way to solve it?
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.
>
> It seems the HTTP protocol doesn't have anything resembling a
> "global timeout" for a given connection (e.g. after x seconds,
> close the receiving channel even if server hasn't finished
> sending), and thus normally httpclient doesn't provide such a
> thing. Do you think this should be investigated/implemented in
> some way?
I do not recall HTTP protocol as such dealing with timeouts in any way.
I may be wrong, though. This is certainly not a protocol concern.
HttpClient does provide so called socket timeout. When set to a positive
number, the connection will terminate with an IOException after the
specified period of inactivity:
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#setTimeout(int)
Hope this helps
Oleg
>
> Thanks, and best regards.
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Hi Michael,
> Closing idle connections may also be of use. This feature has been
> added in HttpClient 3.0alpha2 and the forthcoming HttpClient 2.0.2 via
> HttpConnectionManager.closeIdleConnections() and the
> o.a.c.httpclient.util.IdleConnectionTimeoutThread.
Is it different from 2.0's HttpClient.setTimeout()? We already
use that, our problem is not idle connections but "runaway"
connections: servers which send data very slowly or which send
forever (without a Content-Length header).
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Michael Becke <be...@u.washington.edu>.
Hello Guillaume,
Closing idle connections may also be of use. This feature has been
added in HttpClient 3.0alpha2 and the forthcoming HttpClient 2.0.2 via
HttpConnectionManager.closeIdleConnections() and the
o.a.c.httpclient.util.IdleConnectionTimeoutThread.
Mike
On Oct 1, 2004, at 6:57 AM, Guillaume Cottenceau wrote:
> Hello,
>
> We use HttpClient for performing several HTTP post in parallel in
> our applications. We have a problem when the server(s) receiving
> our HTTP post either answers very slowly, or goes mad and sends
> garbage data over and over: the connection stays open forever,
> but more important, the Java threads as well. We have situations
> where we reach the maximum of Java threads our (tomcat)
> application is configured to handle, and our whole application is
> then unusable.
>
> It seems that java.nio is capable of using only one thread for
> several lowlevel (OS) socket connections, and is actually also
> quite efficient.
>
> I have seen that Oleg Kalnichevski has already expressed his
> views several times on the subject, and I have seen that you want
> to keep 1.2 compatibility, so java.nio out.
>
> http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/
> msg05551.html
> http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/
> msg06998.html
>
> (btw, I don't agree with "in my opinion there's absolutely
> nothing that NIO can bring in in terms of performance to
> client-side applications" - well I agree that pure "performance"
> is not the problem but threads and memory consumption surely is -
> so in my opinion there is a lot to win with java.nio in
> httpclient)
>
> My question is, since you don't want to lose 1.2 compatibility
> before 4.0, is there then a way to solve a typical "too many
> threads" problem such as the one we have? Do you people never had
> the same problem? Or have found a way to solve it?
>
> It seems the HTTP protocol doesn't have anything resembling a
> "global timeout" for a given connection (e.g. after x seconds,
> close the receiving channel even if server hasn't finished
> sending), and thus normally httpclient doesn't provide such a
> thing. Do you think this should be investigated/implemented in
> some way?
>
> Thanks, and best regards.
>
> --
> Guillaume Cottenceau
>
> ---------------------------------------------------------------------
> 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: threads problem with many connections
Posted by Oleg Kalnichevski <ol...@bearingpoint.com>.
> Is it considered safe to interrupt the execute task that way? Is
> method.releaseConnection() the way to go for full cleanup of
> underlying resources, or the interruption might leave things in a
> bad state?
There's no definitive answer to this question. TimeoutController does
not actually interrupt the method execution. All is does is leaving the
client object at the mercy of garbage collector. The client may linger
in the memory until the second coming or get GCed in a reasonable amount
of time. The exact behaviour is unfortunately JRE specific.
Oleg
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Ortwin Glück <or...@nose.ch>.
Guillaume Cottenceau wrote:
> Ok, thanks for this precise code excerpt.
Welcome...
> Is it considered safe to interrupt the execute task that way?
Define 'safe'...
> Is
> method.releaseConnection() the way to go for full cleanup of
> underlying resources, or the interruption might leave things in a
> bad state?
Paranoid code:
import org.apache.commons.httpclient.util.TimeoutController;
Runnable task = new Runnable() {
public void run() {
try {
client.execute(method);
} finally {
method.releaseConnection();
}
}
}
long timeout = ...; //millis
try {
TimeoutController.execute(task, timeout);
} catch(TimeoutController.TimeoutException e) {
/* task has been sent an interrupt signal by now */
}
That way the connection will be returned to an eventual connection pool.
It's just not well defined when that will happen. You might want to use
the SimpleConnectionManager instead and create a new HttpClient object
for every request if you want to be really safe against resource leaks.
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Ortwin Glück <ortwin.glueck 'at' nose.ch> writes:
> What you could do, is the following then:
>
> Wrap the client.execute call:
>
> import org.apache.commons.httpclient.util.TimeoutController;
>
> Runnable task = new Runnable() {
> public void run() {
> client.execute(method);
> }
> }
> long timeout = ...; //millis
> try {
> TimeoutController.execute(task, timeout);
> } catch(TimeoutController.TimeoutException e) {
> /* task has been sent an interrupt signal by now */
> }
Ok, thanks for this precise code excerpt.
Is it considered safe to interrupt the execute task that way? Is
method.releaseConnection() the way to go for full cleanup of
underlying resources, or the interruption might leave things in a
bad state?
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Ortwin Glück <or...@nose.ch>.
Guillaume Cottenceau wrote:
>>What 'thing'? Abort? see HttpMethod#abort in 3.0
>
>
> I was assuming stable httpclient, sorry to not making it clear
> before.
All right. It's true that 2.0 does not have built-in abort due to design
limits.
> I can't say for 3.0 but in 2.0 it seems that client.execute is
> blocked until the server finishes sending the headers (does make
> sense because executeMethod returns the HTTP response code).
Correct.
> In
> my upper example (a server not sending any actual header) your
> code excerpt is blocked forever, if I'm correct.
You are.
What you could do, is the following then:
Wrap the client.execute call:
import org.apache.commons.httpclient.util.TimeoutController;
Runnable task = new Runnable() {
public void run() {
client.execute(method);
}
}
long timeout = ...; //millis
try {
TimeoutController.execute(task, timeout);
} catch(TimeoutController.TimeoutException e) {
/* task has been sent an interrupt signal by now */
}
> I see. HttpClient uses socket timeouts for data transfer
> timeouts, following your reasoning this is in the HTTP protocol?
HTTP is a connection based protocol and therefore requires a
connection-aware transport layer. This is normally TCP. Timouts are
available in all modern TCP implementations to prevent OS-level resource
leaks. That's the reason why there is a timeout feature in Java
(TCP-)Sockets.
If you don't like socket timeouts you are free to use a custom socket
factory which produces sockets that behave to your taste.
Ortwin Glück
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Hi Ortwin,
> Guillaume Cottenceau wrote:
> > If, for example, the HTTP server sends one "a" byte once per
> > second forever, HttpClient will never exit from executeMethod -
> > if I'm correct.
>
> Yes. It's up to you to decide if that sort of communication makes
> sense. HTTP allows it however.
It seems that httpclient 2.0 doesn't allow doing such a thing
(aborting a receival from a runaway server)? We're using "stable"
httpclient currently.
> >>receiving data), your application should be able to figure out if it
> >>is legitimate to stay open for such a long time and otherwise just
> >>abort the method.
> > There's no such thing available in HttpClient, as far as I know?
>
> What 'thing'? Abort? see HttpMethod#abort in 3.0
I was assuming stable httpclient, sorry to not making it clear
before.
> > This needs a monitor Thread setting a timeout in our application.
>
> You call
> try {
> client.execute(method)
> s = method.getResponseAsStream
> try {
> processStream(s)
> } catch(MyException) {
> method.abort();
> }
> } finally {
> method.releaseConnection();
> }
I can't say for 3.0 but in 2.0 it seems that client.execute is
blocked until the server finishes sending the headers (does make
sense because executeMethod returns the HTTP response code). In
my upper example (a server not sending any actual header) your
code excerpt is blocked forever, if I'm correct.
> > It could make sense to implement this timeout in HttpClient, as
> > I've said in previous mail, however I am not sure it is "allowed"
> > by the HTTP protocol.
>
> No it doesn't. HttpClient doesn't care what you send over the wire,
> and it does not care how fast you are doing this either, because HTTP
> does not specify that of course. Your problem is completely in the
> application domain and not in the protocol domain.
I see. HttpClient uses socket timeouts for data transfer
timeouts, following your reasoning this is in the HTTP protocol?
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Ortwin Glück <or...@nose.ch>.
Guillaume Cottenceau wrote:
> If, for example, the HTTP server sends one "a" byte once per
> second forever, HttpClient will never exit from executeMethod -
> if I'm correct.
Yes. It's up to you to decide if that sort of communication makes sense.
HTTP allows it however.
>
>>2. Open connections
>>You can set timeouts for idle connections, so you will get a timeout
>>exception after a while. If the connection is active (i.e. client is
>
>
> Yes, but that's out of the scope of the described problem.
Sorry if I am missing the point!?
>
>>receiving data), your application should be able to figure out if it
>>is legitimate to stay open for such a long time and otherwise just
>>abort the method.
>
>
> There's no such thing available in HttpClient, as far as I know?
What 'thing'? Abort? see HttpMethod#abort in 3.0
> This needs a monitor Thread setting a timeout in our application.
You call
try {
client.execute(method)
s = method.getResponseAsStream
try {
processStream(s)
} catch(MyException) {
method.abort();
}
} finally {
method.releaseConnection();
}
Inside your stream processing you are free to throw an exception.
> It could make sense to implement this timeout in HttpClient, as
> I've said in previous mail, however I am not sure it is "allowed"
> by the HTTP protocol.
No it doesn't. HttpClient doesn't care what you send over the wire, and
it does not care how fast you are doing this either, because HTTP does
not specify that of course. Your problem is completely in the
application domain and not in the protocol domain.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Guillaume Cottenceau <gc...@mnc.ch>.
Ortwin Glück <ortwin.glueck 'at' nose.ch> writes:
> Guillaume Cottenceau wrote:
>
> > Hello,
> > We use HttpClient for performing several HTTP post in parallel in
> > our applications. We have a problem when the server(s) receiving
> > our HTTP post either answers very slowly, or goes mad and sends
> > garbage data over and over: the connection stays open forever,
> > but more important, the Java threads as well.
>
> Those are all problems you can solve:
>
> 1. Garabage data
> If it violates HTTP, you will get an appropriate exception. If the
> content is not meaningful to you, your application should be able to
> figure that out and abort the method.
If, for example, the HTTP server sends one "a" byte once per
second forever, HttpClient will never exit from executeMethod -
if I'm correct.
> 2. Open connections
> You can set timeouts for idle connections, so you will get a timeout
> exception after a while. If the connection is active (i.e. client is
Yes, but that's out of the scope of the described problem.
> receiving data), your application should be able to figure out if it
> is legitimate to stay open for such a long time and otherwise just
> abort the method.
There's no such thing available in HttpClient, as far as I know?
This needs a monitor Thread setting a timeout in our application.
It could make sense to implement this timeout in HttpClient, as
I've said in previous mail, however I am not sure it is "allowed"
by the HTTP protocol.
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Ortwin Glück <or...@nose.ch>.
Guillaume Cottenceau wrote:
> Hello,
>
> We use HttpClient for performing several HTTP post in parallel in
> our applications. We have a problem when the server(s) receiving
> our HTTP post either answers very slowly, or goes mad and sends
> garbage data over and over: the connection stays open forever,
> but more important, the Java threads as well.
Those are all problems you can solve:
1. Garabage data
If it violates HTTP, you will get an appropriate exception. If the
content is not meaningful to you, your application should be able to
figure that out and abort the method.
2. Open connections
You can set timeouts for idle connections, so you will get a timeout
exception after a while. If the connection is active (i.e. client is
receiving data), your application should be able to figure out if it is
legitimate to stay open for such a long time and otherwise just abort
the method.
I can't see any problem with HttpClient here.
Ortwin Glück
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: threads problem with many connections
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Guillaume,
have you considered implementing your own connection manager?
But I would start with tuning the parameters of the existing one.
If it is a realistic scenario that each service thread executes a
POST at the same time, increase the number of connections in
total and per host to the number of threads.
This will not solve the "garbage over and over" problem, though.
If it is acceptable performance-wise, you can disable connection
re-use. I'm not familiar with the implementation, but it might
prevent the connection manager from reading the response body.
cheers,
Roland
Guillaume Cottenceau <gc...@mnc.ch>
Sent by: gc@mnc.ch
01.10.2004 12:57
Please respond to
"Commons HttpClient Project"
To
commons-httpclient-dev@jakarta.apache.org
cc
Subject
threads problem with many connections
Hello,
We use HttpClient for performing several HTTP post in parallel in
our applications. We have a problem when the server(s) receiving
our HTTP post either answers very slowly, or goes mad and sends
garbage data over and over: the connection stays open forever,
but more important, the Java threads as well. We have situations
where we reach the maximum of Java threads our (tomcat)
application is configured to handle, and our whole application is
then unusable.
It seems that java.nio is capable of using only one thread for
several lowlevel (OS) socket connections, and is actually also
quite efficient.
I have seen that Oleg Kalnichevski has already expressed his
views several times on the subject, and I have seen that you want
to keep 1.2 compatibility, so java.nio out.
http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg05551.html
http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg06998.html
(btw, I don't agree with "in my opinion there's absolutely
nothing that NIO can bring in in terms of performance to
client-side applications" - well I agree that pure "performance"
is not the problem but threads and memory consumption surely is -
so in my opinion there is a lot to win with java.nio in
httpclient)
My question is, since you don't want to lose 1.2 compatibility
before 4.0, is there then a way to solve a typical "too many
threads" problem such as the one we have? Do you people never had
the same problem? Or have found a way to solve it?
It seems the HTTP protocol doesn't have anything resembling a
"global timeout" for a given connection (e.g. after x seconds,
close the receiving channel even if server hasn't finished
sending), and thus normally httpclient doesn't provide such a
thing. Do you think this should be investigated/implemented in
some way?
Thanks, and best regards.
--
Guillaume Cottenceau
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org