mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee" <sjl...@gmail.com>
Subject Re: connect timeout
Date Tue, 05 Feb 2008 15:46:19 GMT
Right, that's why I said the connect timeout limitation seems tied to the
select timeout...
Hard-coded 1 second select timeout will interfere with sub-second connect
timeout value.  One obvious suggestion is to set the select timeout to be
the same as the connect timeout.  That way, we're pretty sure that the
connect timeout will be honored.

One small drawback is that we'd end up with a busy select loop if the
connect timeout is too small.  This could be prevented by having a minimum
connect/select timeout value...

Also, note that the 1-second timeout is pervasive elsewhere (like processor,
etc.).  Not sure if we need to change them also.  Maybe not right now...

If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit
a patch also...  How's that sound?

BTW, what is up with the 1 second sleep in the try-catch clause in the same
code area?  We can leave it as is?

                } catch (Throwable e) {

                    ExceptionMonitor.getInstance().exceptionCaught(e);


                    try {

                        Thread.sleep(1000);

                    } catch (InterruptedException e1) {

                        ExceptionMonitor.getInstance().exceptionCaught(e1);

                    }

                }

Thanks,
Sangjin


On Feb 5, 2008 7:29 AM, Julien Vermillard <jvermillard@archean.fr> wrote:

> On Tue, 05 Feb 2008 13:55:15 +0100
> Niklas Therning <niklas@trillian.se> wrote:
> > You would also need to make sure that the current IoConnector
> > implementations can support millisecond timeouts. I think that would
> > mean that AbstractPollingIoConnector.Worker needs to be changed.
> > Specifically the line
> >
> >     boolean selected = select(1000);
> >
> > To support milliseconds we could simply change this into
> >
> >     boolean selected = select(1);
> >
> > but that would be very bad for performance.
> >
> > Instead, one could use an adaptive timeout in the call to select()
> > which depends on the current ConnectRequests' timeouts. Or totally
> > redesign things to use a ScheduledExecutorService or similar instead.
> >
>
> Yes Niklas is right, I forgot the impact on worker loop.
>
> At first look an adaptive select timeout or a redesign using some kind
> of ExecutorService doesn't look like a trivial move..
>
> Whats the lowest connect timeout needed if it's under 1 seconds ?
>
> Julien
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message