hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Johnson" <e...@tibco.com>
Subject Re: Performance Issue
Date Mon, 28 Jul 2003 13:58:19 GMT
Kalnichevski, Oleg wrote:

>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.





Mime
View raw message