There goes my half baked patch :(
On Wed, Jul 1, 2015 at 2:20 PM, Vladimir Ozerov
wrote:
> Yes.
>
> On Wed, Jul 1, 2015 at 11:46 AM, Atri Sharma wrote:
>
> > Hrm, got that.
> >
> > So conclusion is to not go ahead with this feature?
> >
> > On Wed, Jul 1, 2015 at 2:14 PM, Vladimir Ozerov
> > w
Yes.
On Wed, Jul 1, 2015 at 11:46 AM, Atri Sharma wrote:
> Hrm, got that.
>
> So conclusion is to not go ahead with this feature?
>
> On Wed, Jul 1, 2015 at 2:14 PM, Vladimir Ozerov
> wrote:
>
> > Atri,
> >
> > If user require first create cache and the start streaming to it, then he
> > can al
Hrm, got that.
So conclusion is to not go ahead with this feature?
On Wed, Jul 1, 2015 at 2:14 PM, Vladimir Ozerov
wrote:
> Atri,
>
> If user require first create cache and the start streaming to it, then he
> can always call Ignite.getOrCreateCache(). The idea here is that we let
> user decide
Atri,
If user require first create cache and the start streaming to it, then he
can always call Ignite.getOrCreateCache(). The idea here is that we let
user decide whether cache creation is necessary or not, instead of always
creating it.
On Wed, Jul 1, 2015 at 11:33 AM, Atri Sharma wrote:
> I
I see, and adding this method will mandate creation of the delegate even
for data streamer?
Is it a bad tradeoff (known bad tradeoff) for the functionality mentioned?
I still feel there might be use case where on the fly streaming is
necessary and low number of caches are used (mitigating this con
For client node it is necessary to perform regular cache operations.
However, data streamer uses completely different logic to perform cache
updates and does not require this delegate.
On Wed, Jul 1, 2015 at 11:24 AM, Atri Sharma wrote:
> Could you explain a bit on when is a cache delegate neede
Could you explain a bit on when is a cache delegate needed? Just trying to
understand context here please.
On Wed, Jul 1, 2015 at 1:50 PM, Vladimir Ozerov
wrote:
> Atri,
>
> Currently if user start data streaming on a client for already started
> cache it doesn't yield in internal cache delegate
Atri,
Currently if user start data streaming on a client for already started
cache it doesn't yield in internal cache delegate creation on the client
what saves memory which is very important for client mode. With proposed
change client will always create cache delegate even if it is not needed.
T
I agree with that but essentially this is same as manually creating before
data streaming. I agree with your point of cache delegation but there might
be usecases where client is fine with this (low number of caches) but may
need functionality to automate cache creation when streaming.
I feel that
Atri,
I thought a little bit more about this. Calling "getOrCreateCache" is not a
good idea when streamer is called from a client node because it will lead
to creating a cache delegate on this node. But with current approach this
is not necessary and client node doesn't spent memory on it.
Theref
I have created IGNITE -1066 for this.
Please see and comment.
On Tue, Jun 30, 2015 at 12:36 PM, Atri Sharma wrote:
> I think it is a good idea but I wonder if it makes sense to also notify to
> the user somehow that a cache was created or not by this function.
>
> Why I feel that is necessary i
I think it is a good idea but I wonder if it makes sense to also notify to
the user somehow that a cache was created or not by this function.
Why I feel that is necessary is because if we are creating caches most of
the time in the function to the user opaquely, it may lead to user
questioning the
Igniters,
Consider the following use case.
1) User configured cache template, but has never accessed it explicitly yet;
2) User calls Ignite.dataStreamer([cacheName]) - exception is thrown
because cache is not started.
I have a feeling that data streamer must have "getOrCreateCache" semantics
so
13 matches
Mail list logo
