hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moshe Ben-Shoham" <mos...@perfectomobile.com>
Subject SO_TIMEOUT on a request level
Date Sun, 25 Oct 2009 13:32:34 GMT


The scenario is as follows: I'm doing two consecutive requests to the
same host, using a multi-threaded (or thread safe) connection pool
manager. The first invocation has a timeout of 10s and the second has a
timeout of 30s. 


In version 3.1 of HttpClient all works well, but in 4.0 I get a timeout
exception in the second request, after ~10 seconds, which means the
first timeout is used.


Looking at the code, I see that in version 3.1, the
HttpMethodDirector.executeWithRetry() method invokes a method named
applyConnectionParams() that took care of setting the timeout taken from
the request on the socket. 


But in version 4.0, the only place I see the timeout is set on the
socket is when DefaultRequestDirector.execute(HttpHost, HttpRequest,
HttpContext) opens a connection using the managedConn.open() method.
Since the connection is reused between the requests, the second request
uses a socket with a timeout of the first request. As a (bad)
workaround, I put on the HttpClient instance a ConnectionReuseStrategy
that always says no to reusing the connection, so a new connection is
created for the second request, with the required timeout.


Am I missing something?




The information contained in this message is proprietary to the sender, protected from disclosure,
and may be privileged. The information is intended to be conveyed only to the designated recipient(s)
of the message. If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, use, distribution or copying of this communication is strictly
prohibited and may be unlawful. If you have received this communication in error, please notify
us immediately by replying to the message and deleting it from your computer. Thank you.

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message