You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Scott Heaberlin <he...@gmail.com> on 2005/03/01 23:55:51 UTC
Re: Commons HttpClient: HttpClient#setConnectionTimeout
Not to bring this thread back up, but I am having a hard time getting
this to work (tried both 2.0.2 and 3.0-rc1)
<code>
//input = my non-null string
HttpClient myClient = new HttpClient();
PostMethod post = new PostMethod("http://localhost:12345");
post.setRequestBody(input);
post.setRequestContentLength(input.length());
httpClient.getHttpConnectionManager().getParams().setConnectionTimeout(5000L);
httpClient.getHttpConnectionManager().getParams().setSoTimeout(5000L);
httpClient.executeMethod(post);
String response = httpMethod.getResponseBodyAsString();
</code>
Run the netcat command, `nc -l -p 12345` (that's a lower case -L) locally.
Now - run the above snippet. You'll see in your netcat console
everything httpclient sends... but don't touch anything. Wait 5000
milliseconds. Wait 10,000 milliseconds. Wait indefinitely...
On my machine (JRE 1.4.2_03) this never ever returns. If I Control-C
(punt) the netcat command, my java app *immediately* receives:
java.net.ConnectException: Connection refused: connect
I am trying to troubleshoot a situation in an application which has
its own "timeout" configuration which is passed directly to
httpclient, but we are seeing in our logs evidence that this timeout
is apparently having no effect and certain http requests we make are
at the mercy of the responding web server.
Any thoughts? Of course the above code sample only works with 3.0+.
I was previously (2.0.2) using the equivalent methods (now deprecated)
directly on the HttpClient instance:
<code>
httpClient.setConnectionTimeout(5000L);
httpClient.setTimeout(5000L);
</code>
Any thoughts? Your help is greatly appreciated,
-Scott
Scott Heaberlin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Commons HttpClient: HttpClient#setConnectionTimeout
Posted by Dylan Stamat <dy...@gmail.com>.
Here's a new one for all of you :)
I've got a PostMethod object, and I'm calling setRequestBody() with an
array of NameValuePair objects... ie:
==========
PostMethod post = new PostMethod(url);
post.setRequestBody(nameValuePairArray);
==========
This is all fine and dandy, however, the host I'm posting this to is
unable to parse encoded data.
The NameValuePair's are encoded by default... but, I'm unable to find
a way to ensure they AREN'T encoded.
I checked out URIUtil, and it has a decode() method... but the process
would then be a lot less straightforward if I had to break up the URL
and piece-meal it back together.
Any ideas ?
On Wed, 2 Mar 2005 17:13:30 -0500, Scott Heaberlin <he...@gmail.com> wrote:
> You are exactly right. eggOnMe = true
>
> Further investigation showed that I was not setting the read (so)
> timeout as I thought. Then when I actually *was* setting soTimeout, I
> found a bug in our own application that was ignoring the timeout value
> from my own configuration - so instead of my expected "quick" timeout,
> httpclient was being set to a normal, much longer timeout. I simply
> wasn't waiting long enough for our default timeout value to expire.
>
> Consequently, I opted to do what one of the previous messages in this
> thread suggested - utilize HttpMethod::abort() to achieve an absolute
> timeout, as our business requirements do not differentiate from
> connection timeout or remote read timeout. For this I have now
> utilized a mechanism very similar to httpclient's own
> TimeoutController class combined with HttpMethod::abort(). This
> approach works wonderfully - ending the http operation regardless of
> the state of the connection or read operations.
>
> Thanks a bunch - and sorry for the confusion.
>
> -Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Commons HttpClient: HttpClient#setConnectionTimeout
Posted by Scott Heaberlin <he...@gmail.com>.
You are exactly right. eggOnMe = true
Further investigation showed that I was not setting the read (so)
timeout as I thought. Then when I actually *was* setting soTimeout, I
found a bug in our own application that was ignoring the timeout value
from my own configuration - so instead of my expected "quick" timeout,
httpclient was being set to a normal, much longer timeout. I simply
wasn't waiting long enough for our default timeout value to expire.
Consequently, I opted to do what one of the previous messages in this
thread suggested - utilize HttpMethod::abort() to achieve an absolute
timeout, as our business requirements do not differentiate from
connection timeout or remote read timeout. For this I have now
utilized a mechanism very similar to httpclient's own
TimeoutController class combined with HttpMethod::abort(). This
approach works wonderfully - ending the http operation regardless of
the state of the connection or read operations.
Thanks a bunch - and sorry for the confusion.
-Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Commons HttpClient: HttpClient#setConnectionTimeout
Posted by Oleg Kalnichevski <ol...@apache.org>.
Works for me as expected. I get a socket timeout exception in 5 secs
[DEBUG] header - ->> "GET / HTTP/1.1[\r][\n]"
[DEBUG] header - ->> "User-Agent: Jakarta Commons-HttpClient/3.0-rc1
[\r][\n]"
[DEBUG] header - ->> "Host: localhost:12345[\r][\n]"
[DEBUG] header - ->> "[\r][\n]"
Exception in thread "main" java.net.SocketTimeoutException: Read timed
out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
...
I am running Fedora Core 3 Linux with the kernel 2.6.10-1.766_FC3smp and
Java 1.4.2-b28.
This seems to be related to your specific platform setup
Oleg
On Tue, 2005-03-01 at 17:55 -0500, Scott Heaberlin wrote:
> Not to bring this thread back up, but I am having a hard time getting
> this to work (tried both 2.0.2 and 3.0-rc1)
>
> <code>
> //input = my non-null string
> HttpClient myClient = new HttpClient();
> PostMethod post = new PostMethod("http://localhost:12345");
> post.setRequestBody(input);
> post.setRequestContentLength(input.length());
> httpClient.getHttpConnectionManager().getParams().setConnectionTimeout(5000L);
> httpClient.getHttpConnectionManager().getParams().setSoTimeout(5000L);
> httpClient.executeMethod(post);
> String response = httpMethod.getResponseBodyAsString();
> </code>
>
> Run the netcat command, `nc -l -p 12345` (that's a lower case -L) locally.
> Now - run the above snippet. You'll see in your netcat console
> everything httpclient sends... but don't touch anything. Wait 5000
> milliseconds. Wait 10,000 milliseconds. Wait indefinitely...
>
> On my machine (JRE 1.4.2_03) this never ever returns. If I Control-C
> (punt) the netcat command, my java app *immediately* receives:
> java.net.ConnectException: Connection refused: connect
>
> I am trying to troubleshoot a situation in an application which has
> its own "timeout" configuration which is passed directly to
> httpclient, but we are seeing in our logs evidence that this timeout
> is apparently having no effect and certain http requests we make are
> at the mercy of the responding web server.
>
> Any thoughts? Of course the above code sample only works with 3.0+.
> I was previously (2.0.2) using the equivalent methods (now deprecated)
> directly on the HttpClient instance:
> <code>
> httpClient.setConnectionTimeout(5000L);
> httpClient.setTimeout(5000L);
> </code>
>
> Any thoughts? Your help is greatly appreciated,
>
> -Scott
>
>
> Scott Heaberlin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org