ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Missing ways to get access to Ignite CacheEntry
Date Fri, 18 Dec 2015 21:23:43 GMT
How would I know how to interpret the returned null?

Can we just have a simple getEntry(K) method that has semantics of the regular get(K)? Why
invent something?

Cheers
Andrey

> From: dsetrakyan@apache.org
> Date: Fri, 18 Dec 2015 12:55:47 -0800
> Subject: Re: Missing ways to get access to Ignite CacheEntry
> To: dev@ignite.apache.org
> 
> On Fri, Dec 18, 2015 at 12:40 PM, Andrey Kornev <andrewkornev@hotmail.com>
> wrote:
> 
> > Dmitriy,
> >
> > I understand that we're talking about Ignite CacheEntry and not JCache's
> > CacheEntry that has no version property to speak of.
> >
> > But I don't understand why the method is named localEntry()? What does
> > "local" mean in this context? Does it mean that I can only use it on the
> > primary node for a given key? What would happen if I call this method on a
> > non-primary node? And what would I do if I needed the entry (along with the
> > valid version it contains) on a non-primary node?
> >
> 
> If the node is either primary or backup, then you will get the entry back.
> Otherwise, you will get null.
> 
> 
> > > From: dsetrakyan@apache.org
> > > Date: Fri, 18 Dec 2015 12:19:01 -0800
> > > Subject: Re: Missing ways to get access to Ignite CacheEntry
> > > To: dev@ignite.apache.org
> > >
> > > 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
> > such
> > > > 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
> > 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
> > 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
> > would
> > > > > 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.com
> > > > >
> > > > > 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
> > entries'
> > > > > > 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
> > case,
> > > > > > 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, 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
> > been
> > > > > > 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
> > structure
> > > > > > > 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
> > value
> > > > > > > that is located in the Ignite cache? This should work perfectly
> > well
> > > > 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
> > that,
> > > > > > 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. It
> > > > > > sounds like
> > > > > > > >   >>> complicated for "just" getting an entry.
But if you say
> > this
> > > > 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éc. 2015 à 11:34, Denis
Magda <
> > > > dmagda@gridgain.com>
> > > > > > a écrit :
> > > > > > > >   >>>
> > > > > > > >   >>>> 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.
> > > > > > > >   >>>>>
> > > > > > > >   >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message