Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > http bug

Reply
Thread Tools

http bug

 
 
Roedy Green
Guest
Posts: n/a
 
      01-20-2010
I have noticed a program that has worked for a long time now just
freezes as if it had a infinite timeout on HTTP GETs. This started
happening with JDK 1,6.0_18. Has anyone else noticed this?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, “How would I develop if it were my money?” I’m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming .
 
Reply With Quote
 
 
 
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      01-20-2010
Roedy Green wrote:

> I have noticed a program that has worked for a long time now just
> freezes as if it had a infinite timeout on HTTP GETs. This started
> happening with JDK 1,6.0_18. Has anyone else noticed this?


Until 1.5. AFAIR there was no setting in HttpUrlConnection
allowing you to reduce the timeout to something lower than
infinity, forcing you to do some workarounds to get a timeout
when connecting or working with Sockets created with
HttpUrlConnection (I assume you are talking about HttpUrlConnection).

Assuming specific timeout-settings is always a bad idea, so you
should set a timeout for yourself instead of hoping that the
default behavior of a VM keeps the same all time.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      01-20-2010
Roedy Green wrote:
>> I have noticed a program that has worked for a long time now just
>> freezes as if it had a infinite timeout on HTTP GETs. *This started
>> happening with JDK 1,6.0_18. *Has anyone else noticed this?

>


Lothar Kimmeringer <(E-Mail Removed)> wrote:
> Until 1.5. AFAIR there was no setting in HttpUrlConnection
> allowing you to reduce the timeout to something lower than
> infinity, forcing you to do some workarounds to get a timeout
> when connecting or working with Sockets created with
> HttpUrlConnection (I assume you are talking about HttpUrlConnection).
>


You know what you get when you assume. The OP provided a dearth of
information about exactly what he's doing. Perhaps he might consider
sharing the details, or even providing an SSCCE.

> Assuming specific timeout-settings is always a bad idea, so you
> should set a timeout for yourself instead of hoping that the
> default behavior of a VM keeps the same all time.
>


--
Lew
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      01-20-2010
Lothar Kimmeringer wrote:
> Roedy Green wrote:
>
>> I have noticed a program that has worked for a long time now just
>> freezes as if it had a infinite timeout on HTTP GETs. This started
>> happening with JDK 1,6.0_18. Has anyone else noticed this?

>
> Until 1.5. AFAIR there was no setting in HttpUrlConnection
> allowing you to reduce the timeout to something lower than
> infinity, forcing you to do some workarounds to get a timeout
> when connecting or working with Sockets created with
> HttpUrlConnection (I assume you are talking about HttpUrlConnection).
>
> Assuming specific timeout-settings is always a bad idea, so you
> should set a timeout for yourself instead of hoping that the
> default behavior of a VM keeps the same all time.
>
>
> Regards, Lothar

I often find the standard HttpUrlConnection lacking, and usually go with
apache commons HttpClient instead. You have more control of the
process, if you care, but it also "works" out-of-the-box if you don't
want to configure it as much.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      01-20-2010
Daniel Pitts wrote:

> I often find the standard HttpUrlConnection lacking, and usually go with
> apache commons HttpClient instead. You have more control of the
> process, if you care, but it also "works" out-of-the-box if you don't
> want to configure it as much.


The last time I checked, GetMethod and PostMethod were two
classes sharing a lot of methods but not a common superclass.
So you end up with code like this

if (performGet) {
methodGet = new GetMethod(host + url);
methodGet.setQueryString(query);
methodGet.setDoAuthentication(authNeeded);
methodGet.getParams().setParameter("http.socket.ti meout",
Integer.valueOf(timeout));
methodGet.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodGet.setRequestHeader("Connection", "keep-alive");
methodGet.setRequestHeader("Cache-Control", "no-cache");
}
else {
methodPost = new PostMethod(host + url);
methodPost.setRequestHeader("Connection", "keep-alive");
methodPost.setDoAuthentication(authNeeded);
methodPost.getParams().setParameter("http.socket.t imeout",
Integer.valueOf(timeout));
methodPost.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodPost.setRequestHeader("Cache-Control", "no-cache");
}
if (methodGet != null){
statuscode = client.executeMethod(methodGet);
}
else{
statuscode = client.executeMethod(methodPost);
}

and so on. If you have a specific HTTP-session to handle
programmatically, HttpClient is nice, but if you have to
build different HTTP-requests in dependence of external
configurations, you have a lot of duplicate code that
is prone to errors.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      01-20-2010
Lothar Kimmeringer wrote:
> Daniel Pitts wrote:
>
>> I often find the standard HttpUrlConnection lacking, and usually go with
>> apache commons HttpClient instead. You have more control of the
>> process, if you care, but it also "works" out-of-the-box if you don't
>> want to configure it as much.

>
> The last time I checked, GetMethod and PostMethod were two
> classes sharing a lot of methods but not a common superclass.
> So you end up with code like this
>
> if (performGet) {
> methodGet = new GetMethod(host + url);
> methodGet.setQueryString(query);
> methodGet.setDoAuthentication(authNeeded);
> methodGet.getParams().setParameter("http.socket.ti meout",
> Integer.valueOf(timeout));
> methodGet.getParams().setParameter(
> HttpMethodParams.RETRY_HANDLER, retryhandler);
> methodGet.setRequestHeader("Connection", "keep-alive");
> methodGet.setRequestHeader("Cache-Control", "no-cache");
> }
> else {
> methodPost = new PostMethod(host + url);
> methodPost.setRequestHeader("Connection", "keep-alive");
> methodPost.setDoAuthentication(authNeeded);
> methodPost.getParams().setParameter("http.socket.t imeout",
> Integer.valueOf(timeout));
> methodPost.getParams().setParameter(
> HttpMethodParams.RETRY_HANDLER, retryhandler);
> methodPost.setRequestHeader("Cache-Control", "no-cache");
> }
> if (methodGet != null){
> statuscode = client.executeMethod(methodGet);
> }
> else{
> statuscode = client.executeMethod(methodPost);
> }
>
> and so on. If you have a specific HTTP-session to handle
> programmatically, HttpClient is nice, but if you have to
> build different HTTP-requests in dependence of external
> configurations, you have a lot of duplicate code that
> is prone to errors.
>
>
> Regards, Lothar

Last time I checked, they both implement HttpMethod and are derived from
HttpMethodBase. Perhaps you had a really old version, or misinterpreted
something else.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-20-2010
Lothar Kimmeringer wrote:
>> The last time I checked, GetMethod and PostMethod were two
>> classes sharing a lot of methods but not a common superclass.
>> So you end up with code like this
>>
>> if (performGet) {
>> * methodGet = new GetMethod(host + url);
>> * methodGet.setQueryString(query);
>> * methodGet.setDoAuthentication(authNeeded);
>> * methodGet.getParams().setParameter("http.socket.ti meout",
>> * *Integer.valueOf(timeout));
>> * methodGet.getParams().setParameter(
>> * *HttpMethodParams.RETRY_HANDLER, retryhandler);
>> * methodGet.setRequestHeader("Connection", "keep-alive");
>> * methodGet.setRequestHeader("Cache-Control", "no-cache");
>> }
>> else {
>> * methodPost = new PostMethod(host + url);
>> * methodPost.setRequestHeader("Connection", "keep-alive");
>> * methodPost.setDoAuthentication(authNeeded);
>> * methodPost.getParams().setParameter("http.socket.t imeout",
>> * *Integer.valueOf(timeout));
>> * methodPost.getParams().setParameter(
>> * *HttpMethodParams.RETRY_HANDLER, retryhandler);
>> * methodPost.setRequestHeader("Cache-Control", "no-cache");
>> }
>> if (methodGet != null){
>> * statuscode = client.executeMethod(methodGet);
>> }
>> else{
>> * statuscode = client.executeMethod(methodPost);
>> }
>>
>> and so on. If you have a specific HTTP-session to handle
>> programmatically, HttpClient is nice, but if you have to
>> build different HTTP-requests in dependence of external
>> configurations, you have a lot of duplicate code that
>> is prone to errors.

>


Daniel Pitts wrote:
> Last time I checked, they both implement HttpMethod and are derived from
> HttpMethodBase. *Perhaps you had a really old version, or misinterpreted
> something else.
>


I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in
the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which
inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem
roughly equivalent to what you're talking about.
<http://hc.apache.org/httpcomponents-...lient/apidocs/
index.html>

From <http://hc.apache.org/>:
"HttpComponents Client is a successor of and replacement for Commons
HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to
upgrade. ...
"Commons HttpClient 3.x codeline is nearing the end of life. All users
of Commons HttpClient 3.x are strongly encouraged to upgrade to
HttpClient 4.0."

--
Lew
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      01-21-2010
Lew wrote:
> Lothar Kimmeringer wrote:
>>> The last time I checked, GetMethod and PostMethod were two
>>> classes sharing a lot of methods but not a common superclass.
>>> So you end up with code like this
>>>
>>> if (performGet) {
>>> methodGet = new GetMethod(host + url);
>>> methodGet.setQueryString(query);
>>> methodGet.setDoAuthentication(authNeeded);
>>> methodGet.getParams().setParameter("http.socket.ti meout",
>>> Integer.valueOf(timeout));
>>> methodGet.getParams().setParameter(
>>> HttpMethodParams.RETRY_HANDLER, retryhandler);
>>> methodGet.setRequestHeader("Connection", "keep-alive");
>>> methodGet.setRequestHeader("Cache-Control", "no-cache");
>>> }
>>> else {
>>> methodPost = new PostMethod(host + url);
>>> methodPost.setRequestHeader("Connection", "keep-alive");
>>> methodPost.setDoAuthentication(authNeeded);
>>> methodPost.getParams().setParameter("http.socket.t imeout",
>>> Integer.valueOf(timeout));
>>> methodPost.getParams().setParameter(
>>> HttpMethodParams.RETRY_HANDLER, retryhandler);
>>> methodPost.setRequestHeader("Cache-Control", "no-cache");
>>> }
>>> if (methodGet != null){
>>> statuscode = client.executeMethod(methodGet);
>>> }
>>> else{
>>> statuscode = client.executeMethod(methodPost);
>>> }
>>>
>>> and so on. If you have a specific HTTP-session to handle
>>> programmatically, HttpClient is nice, but if you have to
>>> build different HTTP-requests in dependence of external
>>> configurations, you have a lot of duplicate code that
>>> is prone to errors.

>
> Daniel Pitts wrote:
>> Last time I checked, they both implement HttpMethod and are derived from
>> HttpMethodBase. Perhaps you had a really old version, or misinterpreted
>> something else.
>>

>
> I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in
> the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which
> inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem
> roughly equivalent to what you're talking about.
> <http://hc.apache.org/httpcomponents-...lient/apidocs/
> index.html>
>
> From <http://hc.apache.org/>:
> "HttpComponents Client is a successor of and replacement for Commons
> HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to
> upgrade. ...
> "Commons HttpClient 3.x codeline is nearing the end of life. All users
> of Commons HttpClient 3.x are strongly encouraged to upgrade to
> HttpClient 4.0."
>
> --
> Lew

Our codebase has been using HttpClient 3.1, so that is why the
discrepancy.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      01-21-2010
On 20-01-2010 14:53, Lothar Kimmeringer wrote:
> Daniel Pitts wrote:
>> I often find the standard HttpUrlConnection lacking, and usually go with
>> apache commons HttpClient instead. You have more control of the
>> process, if you care, but it also "works" out-of-the-box if you don't
>> want to configure it as much.

>
> The last time I checked, GetMethod and PostMethod were two
> classes sharing a lot of methods but not a common superclass.


Sure?

HttpClient 2.0.2 has a common super class.

> So you end up with code like this
>
> if (performGet) {
> methodGet = new GetMethod(host + url);
> methodGet.setQueryString(query);
> methodGet.setDoAuthentication(authNeeded);
> methodGet.getParams().setParameter("http.socket.ti meout",
> Integer.valueOf(timeout));
> methodGet.getParams().setParameter(
> HttpMethodParams.RETRY_HANDLER, retryhandler);
> methodGet.setRequestHeader("Connection", "keep-alive");
> methodGet.setRequestHeader("Cache-Control", "no-cache");
> }
> else {
> methodPost = new PostMethod(host + url);
> methodPost.setRequestHeader("Connection", "keep-alive");
> methodPost.setDoAuthentication(authNeeded);
> methodPost.getParams().setParameter("http.socket.t imeout",
> Integer.valueOf(timeout));
> methodPost.getParams().setParameter(
> HttpMethodParams.RETRY_HANDLER, retryhandler);
> methodPost.setRequestHeader("Cache-Control", "no-cache");
> }


> and so on. If you have a specific HTTP-session to handle
> programmatically, HttpClient is nice, but if you have to
> build different HTTP-requests in dependence of external
> configurations, you have a lot of duplicate code that
> is prone to errors.


Most HTTP request receivers are either POST or GET anyway.

I can not imagine sending the exact same data to an URL
just with different method should be that common.

Arne
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      01-21-2010
On 20-01-2010 18:34, Lew wrote:
> Lothar Kimmeringer wrote:
>>> The last time I checked, GetMethod and PostMethod were two
>>> classes sharing a lot of methods but not a common superclass.
>>> So you end up with code like this
>>>
>>> if (performGet) {
>>> methodGet = new GetMethod(host + url);
>>> methodGet.setQueryString(query);
>>> methodGet.setDoAuthentication(authNeeded);
>>> methodGet.getParams().setParameter("http.socket.ti meout",
>>> Integer.valueOf(timeout));
>>> methodGet.getParams().setParameter(
>>> HttpMethodParams.RETRY_HANDLER, retryhandler);
>>> methodGet.setRequestHeader("Connection", "keep-alive");
>>> methodGet.setRequestHeader("Cache-Control", "no-cache");
>>> }
>>> else {
>>> methodPost = new PostMethod(host + url);
>>> methodPost.setRequestHeader("Connection", "keep-alive");
>>> methodPost.setDoAuthentication(authNeeded);
>>> methodPost.getParams().setParameter("http.socket.t imeout",
>>> Integer.valueOf(timeout));
>>> methodPost.getParams().setParameter(
>>> HttpMethodParams.RETRY_HANDLER, retryhandler);
>>> methodPost.setRequestHeader("Cache-Control", "no-cache");
>>> }
>>> if (methodGet != null){
>>> statuscode = client.executeMethod(methodGet);
>>> }
>>> else{
>>> statuscode = client.executeMethod(methodPost);
>>> }
>>>
>>> and so on. If you have a specific HTTP-session to handle
>>> programmatically, HttpClient is nice, but if you have to
>>> build different HTTP-requests in dependence of external
>>> configurations, you have a lot of duplicate code that
>>> is prone to errors.

>>

>
> Daniel Pitts wrote:
>> Last time I checked, they both implement HttpMethod and are derived from
>> HttpMethodBase. Perhaps you had a really old version, or misinterpreted
>> something else.

>
> I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in
> the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which
> inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem
> roughly equivalent to what you're talking about.
> <http://hc.apache.org/httpcomponents-...lient/apidocs/
> index.html>


Which you explain yourself:

> From<http://hc.apache.org/>:
> "HttpComponents Client is a successor of and replacement for Commons
> HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to
> upgrade. ...
> "Commons HttpClient 3.x codeline is nearing the end of life. All users
> of Commons HttpClient 3.x are strongly encouraged to upgrade to
> HttpClient 4.0."


Version 4.0 is relative new.

And the completely broke existing code, so a lot of people
will use 2.x and 3.x for a long time, because they don't
want to rewrite the code.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
HTTP SOAP/HTTP GET/HTTP POST milan_9211 Software 0 01-10-2011 02:10 PM
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
Split Tunnel Blocks http through tunnel but passes http around tunnel a.nonny mouse Cisco 2 09-19-2004 12:10 AM
Getting "HTTP Error 403 - Forbidden" at http://localhost/quickstart/ASPPlus/ Scott MCSD 1 08-04-2004 05:28 PM
HttpModule -- how to intercept urls like http://localhost/abc/def or http://localhost/abc/def/ where abc, def are non virtual dir Jiong Feng ASP .Net 0 11-19-2003 05:29 AM



Advertisments