I think Luc made some good points here.  If there's no objection
within 3 days, I will change the timing of ConnectFuture notification
in the trunk.

Thanks,
Trustin

On Jan 25, 2008 3:33 AM, Luc Willems <[EMAIL PROTECTED]> wrote:
> On Thursday 24 January 2008 10:55:18 Trustin Lee wrote:
> > Hi,
> >
> > For now, ConnectFuture is notified right after
> > IoHandler.sessionOpened() returns.  This sometimes makes people
> > confused when sessionOpened() doesn't return immediately.
>
> indead , that was one off the problems i noticed when "reconnecting" a few of
> my +1000 connections after they where closed (in a load tool)
>
> > Because the connection is already established but ConnectFuture is not being
> > notified.
>
>  i got into a situation :
>         - my threadpool filter was to busy with connection close/reopen events
>           (it was a fix sized threadpool)
>         - a other thread , thrigged by a timer starts a new connection with
>           timeout(x)
>         - connection was established but sessionOpened was called much
>           to late  > timeout(x)
>         - my connecting thread was waiting all the time :-(
>         - it finally gave up , thinking a connection ERROR occurs because
>           of the timeout, calls ConnectionFuture.cancel() but
>           connection was already created.
>
> now at this point i would retry the connection (after a short "sleep" time ) ,
> but by doing this , i lose my reference to the original ConnectFuture and
> also any change to get my hands on the first IoSession.
>
> > Just calling ConnectFuture.setSession() after sessionCreated() will
> > resolve this issue, but will bring another backward-incompatibility
> > issue.
>
> i would say , if session (= connection = kernel resources (fh ,etc)) is
> created , than signal this.
>
> ofcourse this means that in my situation, i'll get my connection correctly,
> and my write() will block on the overloaded thread pool. this is for me
> not so bad because i have could handle this "nicely"
>
> > What would be the best way to resolve this kind of situation?
>
> just my 2 cent ;-)
>
>
>
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Reply via email to