I would have to give Sangjin's arguments a +0. I think he makes some good points but I don't think I would say that support sub-second timeouts is _critical_ until people start asking for it.
Load balancing is a case where connect timeouts would be important and all of the load balancers I've configured (both hardware and software loadbalancers) default to a connect timeout of > 1 second. -Mike Alex Karasulu wrote: > +1 > > This was well put Sangjin. After reading this I realized that may > deployments of AHC will have similar needs: sub-second timeouts are > critical. > > Alex > > On Feb 10, 2008 7:10 PM, Sangjin Lee <[EMAIL PROTECTED]> wrote: > >> I can see cases where one might need a very short connect timeout. If >> your >> use case requires a very low fault tolerance and if you would rather fail >> calls than waiting for any longer than is necessary, then 1 second might >> not >> be an adequate minimum value. The characteristic would be a high-load >> situation where low latency (i.e. high bandwidth) is normally expected and >> required. >> For example, if one set of services is making calls to another set of >> services within a single network (i.e. intranet) in high volumes, then the >> expectation on the latency is usually very low. Normally calls should >> succeed within a very short amount of time. Suppose the remote services >> start having problems and suddenly connects and reads are taking longer. >> Having a short connect timeout and a short read timeout is a good way to >> *contain* that risk. If connect timeout can only be 1 second or longer, >> then there would be many situations where the problems from that remote >> service will quickly spread over to any calling services and have a >> cascading effect... >> >> Thanks, >> Sangjin >> >> >> On Feb 9, 2008 12:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> >>> On Feb 4, 2008, at 5:29 PM, Sangjin Lee wrote: >>> >>>> I had a quick question on the connect timeout... >>>> The connect timeout supplied to connectors is in the unit of >>>> seconds, and it >>>> appears the minimum value you can use is 1 second ( >>>> AbstractIoConnector.setConnectTimeout() in the case of the trunk). >>>> Is this >>>> by design? I can see cases where one needs to have a shorter connect >>>> timeout, but it seems it is not possible today. One solution might >>>> be to >>>> use ConnectFuture.join() with a timeout, but that works only if you >>>> want to >>>> block until it times out... >>>> >>>> It also seems that this minimum timeout value is somewhat tied to the >>>> timeout value used in the select() loop in the connector, which is >>>> hard >>>> coded to be 1 second. Would it be a good idea to support connect >>>> timeout >>>> values in milliseconds, and make it shorter than 1 second? >>> It doesn't matter to me but I'm just curious. Why would one want a >>> timeout less than a second? >>> >>> >>> Regards, >>> Alan >>> >>> >
