[infinispan-dev] Rethinking asynchronism in Infinispan

[Brian Stansberry]

On 01/13/2010 08:22 AM, Manik Surtani wrote:
> The end result of all this, is that async API calls will be truly non-blocking, and will be able t harness as much parallelism as possible in the system.  Another effect is that we'd have a cleaner internal API which is specifically designed with async operations in mind, and converting any of the async calls to sync calls is trivial (Future.get()) anywhere along the invocation chain.  Also, I think once we have this in place, any async transport modes (REPL_ASYNC, DIST_ASYNC) should be deprecated in favour of an async API, since you get the ability to check that a call completes even though it happens offline.
>

Please don't remove xx_ASYNC. If I use your async API, I will in most 
cases throw away the Future. Forcing JGroups to respond to the RPC and 
correlate the responses is a waste of resources.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat