ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Async cache creation
Date Fri, 21 Aug 2015 14:42:06 GMT
Thanks Yakov!

Well, a client or not a client, one may have plenty of things to do while waiting for a cache
to finish creating. For example, one might like to create more caches...

In any case, I think the reasoning about sync vs async is pretty much the same as with the
data streaming... One might say: I have nothing else to do until my data is done loading...

In practical terms, Ignite could add the async counterparts (returning a Future) for each
of the "Ignite.create" variety as well as "Ignite.cache". Or, alternatively, those methods
could take an optional completion callback. If provided, the method would return immediately
(with a null), and the callback would be called asynchronously once the operation has completed...
Yet another approach would be to move all cache management operations to a newly created Cache
Manager class (a la JCache's CacheManager) that would provide async support via IgniteAsyncSupport.
The final option is do nothing, which is also fine. :)


> Date: Fri, 21 Aug 2015 10:45:59 +0300
> Subject: Re: Async cache creation
> From: yzhdanov@apache.org
> To: dev@ignite.incubator.apache.org
> Andrey, implementation should be easy, since this process uses futures
> internally. Developer should only make them available externally (properly
> wrapping it, of course).
> However, in most cases cache is created from client nodes which literally
> have nothing to do while cache is not yet created.
> Anyone sees necessity in async cache creation?
> --Yakov
> 2015-08-20 20:59 GMT+03:00 Andrey Kornev <andrewkornev@hotmail.com>:
> > Hello,
> >
> > I've been thinking lately how wonderful it would be if one could
> > create/destroy caches asynchronously! Since those are "resource management
> > operations" and they deserve to be asynchronous.
> >
> > At the moment, there is a way to "simulate" such behavior using
> > EVT_CACHE_STARTED/STOPPED events, but the implementation is rather awkward
> > and would be a lot easier if implemented internally.
> >
> > Sounds interesting?
> >
> > Thanks
> > Andrey
> >
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message