ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atri Sharma <atri.j...@gmail.com>
Subject Re: Starting templated cache from data streamer.
Date Wed, 01 Jul 2015 08:46:58 GMT
Hrm, got that.

So conclusion is to not go ahead with this feature?

On Wed, Jul 1, 2015 at 2:14 PM, Vladimir Ozerov <vozerov@gridgain.com>
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 whether cache creation is necessary or not, instead of always
> creating it.
>
> On Wed, Jul 1, 2015 at 11:33 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>
> > 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 concern to a
> > point).
> >
> > On Wed, Jul 1, 2015 at 2:02 PM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > 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 <atri.jiit@gmail.com>
> > wrote:
> > >
> > > > 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 <
> vozerov@gridgain.com>
> > > > wrote:
> > > >
> > > > > 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.
> > > > > This is why I am -1 for this change.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > On Wed, Jul 1, 2015 at 10:06 AM, Atri Sharma <atri.jiit@gmail.com>
> > > > wrote:
> > > > >
> > > > > > 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 we should implement this and document memory
> > implications
> > > > of
> > > > > > this so it can be used for needed use cases.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > On Wed, Jul 1, 2015 at 12:27 PM, Vladimir Ozerov <
> > > vozerov@gridgain.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Therefore, I think we should not implement this provided
that
> > > > > workaround
> > > > > > > exists: user could call "Ignite.getOrCreateCache" manually
> before
> > > > > > starting
> > > > > > > data streaming in case it is really needed.
> > > > > > >
> > > > > > > Vladimir.
> > > > > > >
> > > > > > > On Tue, Jun 30, 2015 at 7:20 PM, Atri Sharma <
> > atri.jiit@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I have created IGNITE -1066 for this.
> > > > > > > >
> > > > > > > > Please see and comment.
> > > > > > > >
> > > > > > > > On Tue, Jun 30, 2015 at 12:36 PM, Atri Sharma <
> > > atri.jiit@gmail.com
> > > > >
> > > > > > > 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 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 performance degradation (minor
though it
> may
> > > be)
> > > > > > since
> > > > > > > > > creating a cache will be a tad more expensive
than just
> > getting
> > > > it.
> > > > > > It
> > > > > > > > > would be worthwhile to atleast log so we can
identify
> > > performance
> > > > > > > issues
> > > > > > > > > later on.
> > > > > > > > >
> > > > > > > > > If you are fine I can make ticket and assign
it to myself.
> > > > > > > > >
> > > > > > > > > On Tue, Jun 30, 2015 at 12:01 PM, Vladimir Ozerov
<
> > > > > > > vozerov@gridgain.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> 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 that user do not have to pre-start cache
explicitly to
> > > start
> > > > > > > loading
> > > > > > > > >> data to it.
> > > > > > > > >>
> > > > > > > > >> Thoughts?
> > > > > > > > >>
> > > > > > > > >> Vladimir.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Atri
> > > > > > > > > *l'apprenant*
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Atri
> > > > > > > > *l'apprenant*
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > >
> > > > > > Atri
> > > > > > *l'apprenant*
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Atri
> > > > *l'apprenant*
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Atri
> > *l'apprenant*
> >
>



-- 
Regards,

Atri
*l'apprenant*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message