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
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
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
Yes, commons-codec is a new dependency in HttpClient 3.0.
Mike
On Sep 30, 2004, at 11:22 PM, paul wrote:
gao, u need to put this jar into the classpath : commons-codec-1.2.jar
- Original Message -
From: gao maosen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 30, 2004
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
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
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
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
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
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
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
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
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
I am off to China now. See you in two weeks, guys.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31471.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31471.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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
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
Oleg,
Again, I appreciate your ongoing help. I have made the changes
according to your recommendations in our previous email.
1. Context Logging - Done
2. I was able to GET the secure file, so I am being authenticated
correctly. I printed the file to the console.
3. Still using NTLM. This
Oleg,
after adding codec as another dependency and upgrading to 3.0-alpha2,
the jelly taglibs were all still working.
HTH,
On Tue, 28 Sep 2004 09:50:59 +1000, Dion Gillard [EMAIL PROTECTED] wrote:
Oleg, I do care.
I've just unfortunately been moving offices, had servers offline, had
a
21 matches
Mail list logo
