Well, this could be useful in many contexts, even outside of infinispan. One thing to consider is the three ways things finish in Futures: completion, cancellation, and exception. I suspect the listener interface may want to handle all three, or some object that encapsulates those states.

I kindof like this flow in that case: Future f = cache.putAsync(k, v).andInform(listener);

where NotifyingFuture has a method: NotifyingFuture andInform(NotifyingFutureListener listener) interesting stuff... what do you think? -Adrian jclouds On Sat, May 16, 2009 at 1:27 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: While the new async API has been getting rave reviews, someone did bring up async notifications. E.g., Future f = cache.putAsync(k, v); f.get(); But what if I don't want to wait on f.get(), I'd rather be told when the future is done so I can do an f.get()? Sounds pretty useful to me. But just wanted to sound you guys on the API choices for notifications. My immediate thought was to use the existing notification API. You register a cache listener, annotate a method with @RpcCallMade, receive an RpcCallMadeEvent. But this is probably pretty useless, since you couldn't associate the notification with the specific put you've just done. Even if you have the key in the event (which is unlikely - since we need to use the same event for all cache operations, some which take > 1 key such as putAll()), multiple threads could be working on the same key. Another approach is to design a sub-interface to Future. NotifyingFuture. public interface NotifyingFuture extends Future { void addListener(NotifyingFutureListener l); } public interface NotifyingFutureListener { void futureDone(Future f); } WDYT? -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cache cache;

You'd probably need to have every call to "getCompletionService" return a new instance. This is so multiple users don't see completed tasks.

If you want a notification handler, simply tell users to create a thread that polls on operations completed.

On Fri, May 15, 2009 at 4:27 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: > While the new async API has been getting rave reviews, someone did > bring up > async notifications. E.g., > > Future f = cache.putAsync(k, v); > f.get(); > > But what if I don't want to wait on f.get(), I'd rather be told > when the > future is done so I can do an f.get()? Kind of hard to understand the use case here. There's Future.isDone() and a Future.get() with timeout. I think the biggest problem I see with the Async design is you're not sure which order multiple operations will complete in. For instance, if you are doing two puts you don't necessary know which order they might complete in, but you want to know when they might complete.

On 05/15/2009 06:27 PM, Manik Surtani wrote: > While the new async API has been getting rave reviews, someone did > bring up async notifications. E.g., > Future f = cache.putAsync(k, v); > f.get(); > But what if I don't want to wait on f.get(), I'd rather be told > when the future is done so I can do an f.get()? In XNIO, I've solved this problem simply by using a new IoFuture type that can have notifiers registered on it, not unlike your NotifyingFuture example (which, by the way, works very well). http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org... Notice a couple of things that I learned the hard way. future.addNotifier() accepts a notifier and an attachment (allowing the same notifier to be reused by the user if so desired). The notifier itself is called in any of three possible cases: success, cancellation (which may not apply to your use case), and failure. The notifier has a single notify method which is called in any case (an IoFuture has a getStatus() method which returns an enum value). There is an abstract class which has separate handleDone/ handleCancelled/handleFailure methods, each with an empty default implementation; this allows users to easily create anonymous classes which only implement, say, handleDone, while still allowing a single method implementation which is called when any status change occurs. Finally, the addNotifier method has a signature like this: public interface IoFuture<T> { ... <A> IoFuture<T> addNotifier(Notifier<? super T, A> notifier, A attachment); ... } This allows users to register notifiers for IoFutures of any superclass type of the result. This means, for example, that a Notifier<Object, ?> can be registered on any IoFuture, while a Notifier<Closeable, ?> can be registered on just about any IoFuture that returns an I/O entity (think async close after an operation completes). One other lesson I've learned that may be useful to you even if you opt to stick with Future<T> is that you should always use Future<? extends Whatever> rather than Future<Whatever>, and encourage your users to do the same, which gives you a little more flexibility with respect to covariance. While I doubt that IoFuture is directly applicable to your situation, hopefully you won't have to relearn the same lessons the hard way. :-) - DML