I would just make 'stale' connection check optional and off per default. Making the check pluggable would require too much of a change for what is essentially a release candidate. That should be better done as a part of 3.0 redesign IMO.As I recall, the "isStale" function solved a problem arose when the server closed its "write" channel, but not its "read" channel. HttpClient would then send a request, and only when it went to read the response would it fail.
Some possible alternatives:
* Only do the isStale check if the connection has been sitting in
the pool for a configurable amount of time. I'm guessing we could
choose a value here between 5 and 30 seconds without any
significant change in behavior, that is to say, connections won't
go stale in less than 20-30s.
* Perhaps the "isStale" check is unnecessary for methods that can
simply repeat themselves, for example, GET, HEAD, OPTION, TRACE. For those methods, we could allow a "retry" to fix the problem. For methods such as POST and PUT, however, the isStale is probably
an essential check.
* Is this a confirmed problem across all VMs and all OSes? Is this
a confirmed problem if not invoking localhost? If it affects one
platform, could we punt on the issue? Which is the specific line
in isStale() that causes the performance degradation? Is there
anyway to speed that one line?
-Eric.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
