Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <SNT147-W80336B17973282387EED30CFE10@phx.gbl>
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>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Fri, 18 Dec 2015 12:19:01 -0800
Message-ID: 
 <CA+0=VoUFMeUmrFQVTWpU2MHGcBQSoNgHgvH-jd4-Up=BJjrzuA@mail.gmail.com>
Subject: Re: Missing ways to get access to Ignite CacheEntry
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a113ad7defbfde5052731db0f

--001a113ad7defbfde5052731db0f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 18, 2015 at 9:47 AM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> Dmitriy,
>
> Based on what criteria does one determine which information is redundant
> and which is not?
>
> To me, if an API declares a method getSomeRedundantInfo(), then the
> implementer has no choice, but to comply with the contract and provide su=
ch
> info. One can't just return a null or ignore it some other way, simply
> because it appears to have some performance impact.


Andrey, the CacheEntry is not the JCache entry, but rather the internal
Ignite entry that you can get when unwrapping the JCache entry. The
unwrapping, obviously, can only happen on the server side. Therefore, 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).

Now I understand that the version() method currently does not work properly
on the server side, but this is something we can easily fix.

Thoughts?


> Besides, the overhead of the version number may turn out to be negligible
> when benchmarked. Most likely there will be near zero overhead (due to th=
e
> way the network stack packs the bytes into the ethernet frames). The
> workaround for the broken API however may be much more expensive in terms
> of performance and user experience.
>
> Please let's keep the API consistent and predictable.
>
> Regards
> Andrey
>
> > From: dsetrakyan@apache.org
> > Date: Fri, 18 Dec 2015 08:41:00 -0800
> > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > To: dev@ignite.apache.org
> >
> > Andrey,
> >
> > The main issue with returning version is sending redundant information
> over
> > the wire. What if we added a method IgniteCache.localEntry(K) which wou=
ld
> > 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, Dec 18, 2015 at 8:23 AM, Andrey Kornev <andrewkornev@hotmail.co=
m
> >
> > wrote:
> >
> > > Denis,
> > >
> > > I'm not suggesting to have every cache read operation return a
> CacheEntry.
> > > The "classical" GridGain used to have a getEntry(key) method that was
> very
> > > useful. The current version of Ignite provides virtually no way of
> > > obtaining a cache entry except thru an iterator, 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,
> > > it is really an off-topic. It just came about as we were looking for =
a
> way
> > > to work around the issue with Ignite query not returning cache entrie=
s'
> > > 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 t=
o
> > > retrieve the CacheEntry by its key.
> > >
> > > But for the sake of completeness I quickly go over the entire use cas=
e,
> > > 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 t=
o
> > > time, 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 bee=
n
> > > updated since the last time the value was computed.
> > >
> > > Otherwise, we return the pre-computed value. Note that we don't want =
to
> > > rerun the computation for each cache update! Only when the users asks
> 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, 18 Dec 2015 13:44:16 +0300
> > > >
> > > > Hi Andrey,
> > > >
> > > > I got you, thanks for the clarification.
> > > >
> > > > So since you're storing a computed value in some local data structu=
re
> > > > what is stored in the Ignite cache as a value in such a case? There
> > > > should be something.
> > > > Why don't you (or can't you) store a version identifier in that val=
ue
> > > > that is located in the Ignite cache? This should work perfectly wel=
l
> for
> > > > you use-case.
> > > >
> > > > Personally I'm against adding CacheEntry to a response of every get
> like
> > > > operation that happens over a cache (get, getAll, SQL & Scan
> queries).
> > > > This will add extra size to every response and only in rare cases
> > > > someone will benefit from it.
> > > > However, 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, what do you think on this=
?
> > > >
> > > >
> > > > Regards,
> > > > Denis
> > > >
> > > >
> > > > On 12/17/2015 9:09 AM, Andrey Kornev wrote:
> > > > > Denis,In this case I used the term "caching" in general sense,
> 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, December 16, 2015 9:48 PM
> > > > > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > > > To:  <dev@ignite.apache.org>
> > > > >
> > > > >
> > > > >                     Hi Romain,
> > > > >
> > > > >   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 serializable.
> //
> > > > >   /
> > > > >
> > > > >
> > > > >   Ignite won't be able to store a value of cache if serialization
> 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, 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/%3CSNT147=
-W14D2736E1374450B685721CF000%40phx.gbl%3E
> > > > >   > the correct usage of the invoke() may be difficult, to put it
> > > politely.
> > > > >   >
> > > > >   > @Denis Very briefly, the use case is "conditional re-compute"=
.
> > > 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 then
> > > cached along with the current version of the cache entry.  The  value
> must
> > > be recomputed on next access only if the entry has been modified.
> > > > >   >
> > > > >   > If anyone has a better idea how to achieve something like tha=
t,
> > > please do share! One constraint is that the computed value is not
> > > serializable.
> > > > >   >
> > > > >   > Cheers
> > > > >   > Andrey
> > > > >   >
> > > > >   >> Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > > >   >> To: dev@ignite.apache.org
> > > > >   >> From: dmagda@gridgain.com
> > > > >   >> Date: Wed, 16 Dec 2015 16:11:48 +0300
> > > > >   >>
> > > > >   >> Romain,
> > > > >   >>
> > > > >   >> If it's implemented this way for now it doesn't mean that we
> can't
> > > > >   >> enhance the API for other use cases ;)
> > > > >   >> 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,
> > > > >   >> Denis
> > > > >   >>
> > > > >   >> On 12/16/2015 1:53 PM, Romain Gilles wrote:
> > > > >   >>> Hi Denis,
> > > > >   >>> Thanks for you replay. And sorry to not double check it
> before.
> > > I see that
> > > > >   >>> if I want to work with CacheEntry, I need to use the invoke
> > > method in order
> > > > >   >>> to return the CacheEntry. This is the way I should do it. I=
t
> > > sounds like
> > > > >   >>> complicated for "just" getting an entry. But if you say thi=
s
> 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,
> > > > >   >>>
> > > > >   >>> Romain.
> > > > >   >>>
> > > > >   >>> Le mer. 16 d=C3=A9c. 2015 =C3=A0 11:34, Denis Magda <
> dmagda@gridgain.com>
> > > a =C3=A9crit :
> > > > >   >>>
> > > > >   >>>> Hi Romain,
> > > > >   >>>>
> > > > >   >>>> As the current documentation of
> > > org.apache.ignite.cache.CacheEntry
> > > > >   >>>> states it's possible to get a reference to CacheEntry and
> its
> > > version
> > > > >   >>>> only for methods that are executed over local data set
> stored
> > > on a node.
> > > > >   >>>> Among such methods are invoke & invokeAll and randomEntry.
> > > > >   >>>>
> > > > >   >>>> You probably can get a CacheEntry and its non null version
> when
> > > a cache
> > > > >   >>>> iterator is in use but the version will be 'null', as far
> as I
> > > remember,
> > > > >   >>>> for those entries that are loaded from remote nodes.
> > > > >   >>>> Presently Ignite doesn't transfer the version from remote
> nodes
> > > as a
> > > > >   >>>> part of response by perform reasons.
> > > > >   >>>>
> > > > >   >>>> Please elaborate more on your particular use case and what
> API
> > > you would
> > > > >   >>>> like to add in order to support it.
> > > > >   >>>>
> > > > >   >>>> --
> > > > >   >>>> Denis
> > > > >   >>>>
> > > > >   >>>> On 12/16/2015 12:58 PM, Romain Gilles wrote:
> > > > >   >>>>> Hi Igniters,
> > > > >   >>>>> 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,V>
> > > > >   >>>>> 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,
> > > > >   >>>>>
> > > > >   >>>>> Romain.
> > > > >   >>>>>
> > > > >   >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
>
>

--001a113ad7defbfde5052731db0f--