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 ;-)
