Hi,
I have reviewed the IoFuture hierarchy we use in Mina 2, and I think we
should change it a lot in MINA 3.
First, we should inherit from the Java Future interface. Mina 2.0 uses
it's own home brew Future for historical reasons : it was not available
in Jdk 1.4, and it was not redesign in MINA 2.0 nor in MIN1 1.1 when we
switched to Jdk 5.
Second, we should be more careful when we use Futures. In Mina 2, we are
misusing Futures in at least two cases :
- it's used when trying to dispose a Service. We create a
disposalFuture, instance of a ServiceOperationFuture, just to wait for
all the session to be done before closing the service. It would be
better to use a specific data structure, like a countdownLatch, to do that.
- The ConnectFuture usage is really bothersome : we use it not only to
wait for a connection to be done, but also to detect the disconnection.
It's totally wrong.
- We also have a ReadFuture which is a bit different beast : it's only
used on client side for people who want to implement a synchronous
operation on top of the asynchronous operations MINA provides. We should
reconsider this approach and make it separated from the main hierarchy.
Otherwise, we should also pick the correct Java objects to manage
synchronization between the Future user (the thread waiting on the
future) and the thread updating it. Right now, it's done through a
setValue(blah) call, but the blah object may be almost anything, so it
does not carry a lot of information. We should also leverage the
standard API, which has a isCancelled() method, not available in Mina 2
API. Using synchronized blocks is probably not the best solution...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
