In the 4.0.1 tutorial I see the following paragraph.

... begin snippet ...
HttpClient tries to mitigate the problem by testing whether the connection is 
'stale', that is no longer valid because it was closed on the server side, 
prior to using the connection for executing an HTTP request. The stale 
connection check is not 100% reliable and adds 10 to 30 ms overhead to each 
request execution. The only feasible solution that does not involve a one 
thread per socket model for idle connections is a dedicated monitor thread used 
to evict connections that are considered expired due to a long period of 
inactivity. The monitor thread can periodically call 
ClientConnectionManager#closeExpiredConnections() method to close all expired 
connections and evict closed connections from the pool. It can also optionally 
call ClientConnectionManager#closeIdleConnections() method to close all 
connections that have been idle over a given period of time.
... end snippet ...

Today we implement both the stale connection checking as well as the 
IdleConnectionTimeoutThread (in 3.1).
I would love to save the 10-30ms overhead but without doing that stale check it 
is possible that a connection was closed (that the Idle monitor may not have 
awoken to catch)..
Sounds like to me the only way to be as close to 100% safe is to implement 
both..

Is that correct?

-k




This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

Reply via email to