hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38231] - request doesn't timeout when response is slow
Date Thu, 12 Jan 2006 23:58:06 GMT
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=38231>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38231





------- Additional Comments From mboyers@yahoo.com  2006-01-13 00:58 -------
I understand.

I did check out the TimeoutController.  It looks like I'll either need to do my
own Thread management or incur the overhead of having a new Thread instantiated
per request.  I'm not very excited about either option, to be honest.

Would it be appropriate to request an enhancement to have a
"setOverallTimeout()" type method added in the future?  The reason this is
important to me is because I use HttpClient in a production environment to pull
dynamic content (HTML) fragments, sometimes from third party hosts.  I don't
want a misbehaved "fragment provider" to be able to consume all of the
connections to that particular host, because often times there are many
"fragment providers" within a single host and a single misbehaved provider could
render them all useless.  Additionally, some of these requests occur on a web
page visitor's request thread, which could leave them hanging indefinitely if a
response is trickling in.  Bottom line is, whatever I set that timeout value to,
I want to know that I'm either going to have a full response at that point or
I'm going to proceed without it.

I'm not familiar enough with the HttpClient code base to know this, so I'll ask.
 You mentioned the various TCP packet exhanges that occur.  Do you have the
capability to set the socket timeout prior to each packet recieved?  If so, can
you point me to the class(es) where this occurs?

Thanks for your time,
Mike

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message