Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Message-ID: <SNT147-W5744BAC213C2E71D64FDA3CFE10@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_dac37ed8-e153-4f3e-aa4a-7883a9a4ef5c_"
From: Andrey Kornev <andrewkornev@hotmail.com>
To: "dev@ignite.apache.org" <dev@ignite.apache.org>
Subject: RE: Missing ways to get access to Ignite CacheEntry
Date: Fri, 18 Dec 2015 12:40:07 -0800
Importance: Normal
In-Reply-To: 
 <CA+0=VoUFMeUmrFQVTWpU2MHGcBQSoNgHgvH-jd4-Up=BJjrzuA@mail.gmail.com>
References: 
 <CAHG4OXtKE23FU9EHecFpEGxg_d4cOitft-QKzfZdBpv_+5WruA@mail.gmail.com>,<56713E12.6000504@gridgain.com>
 <CAHG4OXsvrsn7z4qBTZ1-6v=1c1S436wnXeXQqgpC9zU-_-Pihw@mail.gmail.com>,<56716314.3050803@gridgain.com>
 <SNT147-W1554648E7F78F73768B9AACFEF0@phx.gbl>,<56724C8E.70607@gridgain.com>
 <SNT406-EAS234FB8FB35D9D04CA370D91CFE00@phx.gbl>,<5673E380.1090908@gridgain.com>
 <SNT147-W867886A07FA8985C1BC85ECFE10@phx.gbl>,<CA+0=VoXjihtW3M46z8sLXCpSFbmfE2Td5KYgOBpNCiTRdXi0+A@mail.gmail.com>
 <SNT147-W80336B17973282387EED30CFE10@phx.gbl>,<CA+0=VoUFMeUmrFQVTWpU2MHGcBQSoNgHgvH-jd4-Up=BJjrzuA@mail.gmail.com>
MIME-Version: 1.0

--_dac37ed8-e153-4f3e-aa4a-7883a9a4ef5c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dmitriy=2C

I understand that we're talking about Ignite CacheEntry and not JCache's Ca=
cheEntry that has no version property to speak of.

But I don't understand why the method is named localEntry()? What does "loc=
al" mean in this context? Does it mean that I can only use it on the primar=
y node for a given key? What would happen if I call this method on a non-pr=
imary node? And what would I do if I needed the entry (along with the valid=
 version it contains) on a non-primary node?

Thanks
Andrey

> From: dsetrakyan@apache.org
> Date: Fri=2C 18 Dec 2015 12:19:01 -0800
> Subject: Re: Missing ways to get access to Ignite CacheEntry
> To: dev@ignite.apache.org
>=20
> On Fri=2C Dec 18=2C 2015 at 9:47 AM=2C Andrey Kornev <andrewkornev@hotmai=
l.com>
> wrote:
>=20
> > Dmitriy=2C
> >
> > Based on what criteria does one determine which information is redundan=
t
> > and which is not?
> >
> > To me=2C if an API declares a method getSomeRedundantInfo()=2C then the
> > implementer has no choice=2C but to comply with the contract and provid=
e such
> > info. One can't just return a null or ignore it some other way=2C simpl=
y
> > because it appears to have some performance impact.
>=20
>=20
> Andrey=2C the CacheEntry is not the JCache entry=2C but rather the intern=
al
> Ignite entry that you can get when unwrapping the JCache entry. The
> unwrapping=2C obviously=2C can only happen on the server side. Therefore=
=2C I am
> suggesting that we also add a localEntry(K) method which will provide the
> entry API on the server side directly (not from iterator or EP).
>=20
> Now I understand that the version() method currently does not work proper=
ly
> on the server side=2C but this is something we can easily fix.
>=20
> Thoughts?
>=20
>=20
> > Besides=2C the overhead of the version number may turn out to be neglig=
ible
> > when benchmarked. Most likely there will be near zero overhead (due to =
the
> > way the network stack packs the bytes into the ethernet frames). The
> > workaround for the broken API however may be much more expensive in ter=
ms
> > of performance and user experience.
> >
> > Please let's keep the API consistent and predictable.
> >
> > Regards
> > Andrey
> >
> > > From: dsetrakyan@apache.org
> > > Date: Fri=2C 18 Dec 2015 08:41:00 -0800
> > > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > To: dev@ignite.apache.org
> > >
> > > Andrey=2C
> > >
> > > The main issue with returning version is sending redundant informatio=
n
> > over
> > > the wire. What if we added a method IgniteCache.localEntry(K) which w=
ould
> > > return a local entry instance with a version. You would only be able =
to
> > > invoke this method on the server node (not client).
> > >
> > > Would this work for you?
> > >
> > > D.
> > >
> > > On Fri=2C Dec 18=2C 2015 at 8:23 AM=2C Andrey Kornev <andrewkornev@ho=
tmail.com
> > >
> > > wrote:
> > >
> > > > Denis=2C
> > > >
> > > > I'm not suggesting to have every cache read operation return a
> > CacheEntry.
> > > > The "classical" GridGain used to have a getEntry(key) method that w=
as
> > very
> > > > useful. The current version of Ignite provides virtually no way of
> > > > obtaining a cache entry except thru an iterator=2C or using an
> > EntryProcessor
> > > > invocation which seems more like a hack.
> > > >
> > > > As for the question of what's stored in Ignite cache and the
> > pre-compute=2C
> > > > it is really an off-topic. It just came about as we were looking fo=
r a
> > way
> > > > to work around the issue with Ignite query not returning cache entr=
ies'
> > > > version numbers in the result iterator. (There is now a ticket that
> > > > addresses this issue:
> > https://issues.apache.org/jira/browse/IGNITE-2202
> > > > )This is when we realized that there is no longer any way in Ignite=
 to
> > > > retrieve the CacheEntry by its key.
> > > >
> > > > But for the sake of completeness I quickly go over the entire use c=
ase=2C
> > > > because it seems I wasn't clear enough in the previous post.
> > > >
> > > > Ignite cache holds the data entries that are used as the input into
> > some
> > > > expensive computation. The data in the cache gets updated from time=
 to
> > > > time=2C the computation only needs to be re-run
> > > > - on-demand -- when a user asks for the computed value and
> > > > - the pre-computed value is obsolete -- the source cache data has b=
een
> > > > updated since the last time the value was computed.
> > > >
> > > > Otherwise=2C we return the pre-computed value. Note that we don't w=
ant to
> > > > rerun the computation for each cache update! Only when the users as=
ks
> > for
> > > > it.
> > > >
> > > > I hope it make it more clear now.
> > > >
> > > > Thanks
> > > > Andrey
> > > >
> > > > > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > > > To: dev@ignite.apache.org
> > > > > From: dmagda@gridgain.com
> > > > > Date: Fri=2C 18 Dec 2015 13:44:16 +0300
> > > > >
> > > > > Hi Andrey=2C
> > > > >
> > > > > I got you=2C thanks for the clarification.
> > > > >
> > > > > So since you're storing a computed value in some local data struc=
ture
> > > > > what is stored in the Ignite cache as a value in such a case? The=
re
> > > > > should be something.
> > > > > Why don't you (or can't you) store a version identifier in that v=
alue
> > > > > that is located in the Ignite cache? This should work perfectly w=
ell
> > for
> > > > > you use-case.
> > > > >
> > > > > Personally I'm against adding CacheEntry to a response of every g=
et
> > like
> > > > > operation that happens over a cache (get=2C getAll=2C SQL & Scan
> > queries).
> > > > > This will add extra size to every response and only in rare cases
> > > > > someone will benefit from it.
> > > > > However=2C what if we add a special configuration parameter to
> > > > > CacheConfiguration that will manage whether CacheEntry has to be
> > passed
> > > > > as a part of a response or not? Igniters=2C what do you think on =
this?
> > > > >
> > > > >
> > > > > Regards=2C
> > > > > Denis
> > > > >
> > > > >
> > > > > On 12/17/2015 9:09 AM=2C Andrey Kornev wrote:
> > > > > > Denis=2CIn this case I used the term "caching" in general sense=
=2C
> > meaning
> > > > saving the computed value for later. I didn't mean the Ignite
> > cache.Sorry
> > > > about the confusion.Andrey
> > > > > >      _____________________________
> > > > > > From: Denis Magda <dmagda@gridgain.com>
> > > > > > Sent: Wednesday=2C December 16=2C 2015 9:48 PM
> > > > > > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > > > > To:  <dev@ignite.apache.org>
> > > > > >
> > > > > >
> > > > > >                     Hi Romain=2C
> > > > > >
> > > > > >   I'm a bit confused cause initially you saying that
> > > > > >
> > > > > >   /The value is computed on first access and it is then cached
> > > > > >
> > > > > >   /and then you add that
> > > > > >
> > > > > >   /One constraint is that the computed value is not serializabl=
e.
> > //
> > > > > >   /
> > > > > >
> > > > > >
> > > > > >   Ignite won't be able to store a value of cache if serializati=
on
> > is
> > > > not
> > > > > >   supported for it by some reason.
> > > > > >
> > > > > >   Please clarify here. Probably I'm missing something from your
> > > > description.
> > > > > >
> > > > > >   --
> > > > > >   Denis
> > > > > >
> > > > > >   On 12/16/2015 6:21 PM=2C Andrey Kornev wrote:
> > > > > >   > Romain
> > > > > >   >
> > > > > >   > I suggest you be very careful using the invoke()
> > functionality. As
> > > > explained in this posting (and the follow-ups)
> > > > > >   >
> > > >
> > http://mail-archives.apache.org/mod_mbox/ignite-dev/201511.mbox/%3CSNT1=
47-W14D2736E1374450B685721CF000%40phx.gbl%3E
> > > > > >   > the correct usage of the invoke() may be difficult=2C to pu=
t it
> > > > politely.
> > > > > >   >
> > > > > >   > @Denis Very briefly=2C the use case is "conditional re-comp=
ute".
> > > > There is a pretty expensive computation that needs to be applied to
> > each
> > > > entry on demand. The value is computed on first access and it is th=
en
> > > > cached along with the current version of the cache entry.  The  val=
ue
> > must
> > > > be recomputed on next access only if the entry has been modified.
> > > > > >   >
> > > > > >   > If anyone has a better idea how to achieve something like t=
hat=2C
> > > > please do share! One constraint is that the computed value is not
> > > > serializable.
> > > > > >   >
> > > > > >   > Cheers
> > > > > >   > Andrey
> > > > > >   >
> > > > > >   >> Subject: Re: Missing ways to get access to Ignite CacheEnt=
ry
> > > > > >   >> To: dev@ignite.apache.org
> > > > > >   >> From: dmagda@gridgain.com
> > > > > >   >> Date: Wed=2C 16 Dec 2015 16:11:48 +0300
> > > > > >   >>
> > > > > >   >> Romain=2C
> > > > > >   >>
> > > > > >   >> If it's implemented this way for now it doesn't mean that =
we
> > can't
> > > > > >   >> enhance the API for other use cases =3B)
> > > > > >   >> As I said presently it's supported for limited number of
> > methods
> > > > mostly
> > > > > >   >> by performance reasons.
> > > > > >   >>
> > > > > >   >> Please go ahead and try invoke/invokeAll and if it doesn't
> > work
> > > > fine for
> > > > > >   >> you we can keep discussing what to do next.
> > > > > >   >>
> > > > > >   >> Regards=2C
> > > > > >   >> Denis
> > > > > >   >>
> > > > > >   >> On 12/16/2015 1:53 PM=2C Romain Gilles wrote:
> > > > > >   >>> Hi Denis=2C
> > > > > >   >>> Thanks for you replay. And sorry to not double check it
> > before.
> > > > I see that
> > > > > >   >>> if I want to work with CacheEntry=2C I need to use the in=
voke
> > > > method in order
> > > > > >   >>> to return the CacheEntry. This is the way I should do it.=
 It
> > > > sounds like
> > > > > >   >>> complicated for "just" getting an entry. But if you say t=
his
> > is
> > > > the way I
> > > > > >   >>> will do it like that. I was just think that it could be a
> > common
> > > > use case
> > > > > >   >>> and therefore provide it as a shortcut.
> > > > > >   >>>
> > > > > >   >>> Thanks=2C
> > > > > >   >>>
> > > > > >   >>> Romain.
> > > > > >   >>>
> > > > > >   >>> Le mer. 16 d=E9c. 2015 =E0 11:34=2C Denis Magda <
> > dmagda@gridgain.com>
> > > > a =E9crit :
> > > > > >   >>>
> > > > > >   >>>> Hi Romain=2C
> > > > > >   >>>>
> > > > > >   >>>> As the current documentation of
> > > > org.apache.ignite.cache.CacheEntry
> > > > > >   >>>> states it's possible to get a reference to CacheEntry an=
d
> > its
> > > > version
> > > > > >   >>>> only for methods that are executed over local data set
> > stored
> > > > on a node.
> > > > > >   >>>> Among such methods are invoke & invokeAll and randomEntr=
y.
> > > > > >   >>>>
> > > > > >   >>>> You probably can get a CacheEntry and its non null versi=
on
> > when
> > > > a cache
> > > > > >   >>>> iterator is in use but the version will be 'null'=2C as =
far
> > as I
> > > > remember=2C
> > > > > >   >>>> for those entries that are loaded from remote nodes.
> > > > > >   >>>> Presently Ignite doesn't transfer the version from remot=
e
> > nodes
> > > > as a
> > > > > >   >>>> part of response by perform reasons.
> > > > > >   >>>>
> > > > > >   >>>> Please elaborate more on your particular use case and wh=
at
> > API
> > > > you would
> > > > > >   >>>> like to add in order to support it.
> > > > > >   >>>>
> > > > > >   >>>> --
> > > > > >   >>>> Denis
> > > > > >   >>>>
> > > > > >   >>>> On 12/16/2015 12:58 PM=2C Romain Gilles wrote:
> > > > > >   >>>>> Hi Igniters=2C
> > > > > >   >>>>> I'm looking for a way to get access to the Ignite
> > CacheEntry.
> > > > For now
> > > > > >   >>>> this
> > > > > >   >>>>> is the ways I found:
> > > > > >   >>>>>
> > > > > >   >>>>>       - Through the queris
> > > > > >   >>>>>       - Through jsr 107 Cache Iterable
> > > > > >   >>>>>       - Through jsr 107 Cache itterator
> > > > > >   >>>>>       - Through IgniteCache::randomEntry()
> > > > > >   >>>>>
> > > > > >   >>>>> If I remember correctly it was possible to get the
> > CacheEntry
> > > > from a
> > > > > >   >>>> given
> > > > > >   >>>>> key in old version of gridgain community
> > > > > >   >>>>> version: GridCacheProjection::entry(K key)
> > GridCacheEntry<K=2CV>
> > > > > >   >>>>> I think it could be a good to introduce this feature at
> > > > IgniteCache
> > > > > >   >>>> level.
> > > > > >   >>>>> Or maybe there is an other way to do it.
> > > > > >   >>>>>
> > > > > >   >>>>> Thanks=2C
> > > > > >   >>>>>
> > > > > >   >>>>> Romain.
> > > > > >   >>>>>
> > > > > >   >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> >
> >
 		 	   		  =

--_dac37ed8-e153-4f3e-aa4a-7883a9a4ef5c_--