[infinispan-dev] Rethinking asynchronism in Infinispan

[Manik Surtani]

On 15 Jan 2010, at 21:21, Brian Stansberry wrote:

> 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.

Fair point, there would still be use cases that value performance over "reliable async".  :)

> 
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org