Re: [infinispan-dev] Rethinking asynchronism in Infinispan

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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev