[HTTPCLIENT-1609] Implementation of validate() Required In CPool

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.4 Final
• Fix Version/s: 4.4.1
• Component/s: HttpClient (classic)
• Labels: patch
• Assignee: Unassigned
• Reporter: Charles Lip
• Created: 11/Feb/15 02:14
• Updated: 04/May/17 09:49
• Resolved: 11/Feb/15 08:47

Description

In httpclient-4.4, org.apache.http.impl.conn.CPool directly inherits the dummy method validate() from abstract class org.apache.http.pool.AbstractConnPool:-

/** * @since 4.4 */
protected boolean validate(final E entry)

{ return true; }

Given that validate() always return TRUE, a critical portion of codes related to "closing stale connection" in method AbstractConnPool .getPoolEntryBlocking() is rendered unreachable.

Snippet of codes showing the unreachable part of method AbstractConnPool .getPoolEntryBlocking():
....
else if (this.validateAfterInactivity > 0) {
if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
if (!validate(entry))

{ entry.close(); //unreachable }

}
}
... ..

PoolingHttpClientConnectionManager, which is supported by CPool, is impaired by this defect for stale connection management logics involving validateAfterInactivity property.

CPool class needs a proper implementation of method validate(); a possible fix would be:

@Override
protected boolean validate(final CPoolEntry entry) {
return !entry.getConnection().isStale();
}

Issue Links

• is duplicated by: HTTPCLIENT-1610 Stale connections in pool cause NoHttpResponseException
• is duplicated by: HTTPCLIENT-1635 Change in the way to check stale connection in 4.4 seems to cause a lot of retry