On Mar 1, 2010, at 4:31 AM, Emmanuel Lecharny wrote:
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.
I agree, the IoFuture hierarchy is bewildering. All we need is
something like:
public interface IoFuture<V> extends Future<V>
{
public IoFuture<V> register(IoFutureListener<V> listener);
}
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.
That seems like an implementation issue. I think that there's merit
in using a well known pattern such as Future.
- 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.
Can you give a more concrete example? What extra information does
one need and when?
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...
Can you give a concrete example to add color to this statement?
Regards,
Alan
