On Feb 11, 2008 1:41 AM, Mike Heath <[EMAIL PROTECTED]> wrote: > 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. >
I think Sangjin and I are asking for it :-). I have a need for this. Why not just enable more resolution and leave it up to the user to decide based on their specific need. Alex > 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 > >>> > >>> > > > >
