Igniters,
I've been working on the task that will let the user to retrieve version related information for a particular Cache.Entry object. All the details are here: https://issues.apache.org/jira/browse/IGNITE-946 VersionedEntry of a given Cache.Entry can be retrieved by a call to 'Cache.Entry.unwrap(VersionedEntry.class)'. I've already fully supported 'unwrap' for Cache.Entry when it is returned from: - Cache.invoke(); - Cache.invokeAll(); - IgniteCache.randomEntry(); The following entry points are left: - Cache.iterator(); - IgniteCache.localEntries(). However, I doubt that it makes sense to support these two last methods. In my understanding a use case scenario of VersionedEntry is the following: the user get a VersionedEntry for a particular key(s) using Cache.invoke, keeps it and then compares with other VersionEntries for the same key retrieved later. I don't think that the user will iterate over a cache using Cache.iterator() or IgniteCache.localEntries() in order to get a version, especially in production. What do you think? Do you see any other real life scenarios I'm missing? -- Denis |
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote:
> Igniters, > > I've been working on the task that will let the user to retrieve version > related information for a particular Cache.Entry object. > All the details are here: https://issues.apache.org/jira/browse/IGNITE-946 > > VersionedEntry of a given Cache.Entry can be retrieved by a call to > 'Cache.Entry.unwrap(VersionedEntry.class)'. > I've already fully supported 'unwrap' for Cache.Entry when it is returned > from: > - Cache.invoke(); > - Cache.invokeAll(); > - IgniteCache.randomEntry(); > > The following entry points are left: > - Cache.iterator(); > - IgniteCache.localEntries(). > > However, I doubt that it makes sense to support these two last methods. > In my understanding a use case scenario of VersionedEntry is the > following: the user get a VersionedEntry for a particular key(s) using > Cache.invoke, keeps it and then compares with other VersionEntries for the > same key retrieved later. > I don't think that the user will iterate over a cache using > Cache.iterator() or IgniteCache.localEntries() in order to get a version, > especially in production. > Denis, what is the reason for not supporting a version on an entry at all times? Is there a specific performance issue or slow down you are concerned with? > > What do you think? Do you see any other real life scenarios I'm missing? > > -- > Denis > |
On 7/30/2015 4:36 PM, Dmitriy Setrakyan wrote: > On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote: > >> Igniters, >> >> I've been working on the task that will let the user to retrieve version >> related information for a particular Cache.Entry object. >> All the details are here: https://issues.apache.org/jira/browse/IGNITE-946 >> >> VersionedEntry of a given Cache.Entry can be retrieved by a call to >> 'Cache.Entry.unwrap(VersionedEntry.class)'. >> I've already fully supported 'unwrap' for Cache.Entry when it is returned >> from: >> - Cache.invoke(); >> - Cache.invokeAll(); >> - IgniteCache.randomEntry(); >> >> The following entry points are left: >> - Cache.iterator(); >> - IgniteCache.localEntries(). >> >> However, I doubt that it makes sense to support these two last methods. >> In my understanding a use case scenario of VersionedEntry is the >> following: the user get a VersionedEntry for a particular key(s) using >> Cache.invoke, keeps it and then compares with other VersionEntries for the >> same key retrieved later. >> I don't think that the user will iterate over a cache using >> Cache.iterator() or IgniteCache.localEntries() in order to get a version, >> especially in production. >> > Denis, what is the reason for not supporting a version on an entry at all > times? Is there a specific performance issue or slow down you are concerned > with? > IgniteCache.localEntries() requires a lot of modifications in Ignite code. That's why I'm interested whether it makes sense to do it or not before start coding. Can't say how the modifications will affect performance, from the first view they shouldn't. -- Denis >> What do you think? Do you see any other real life scenarios I'm missing? >> >> -- >> Denis >> |
In reply to this post by dsetrakyan
On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]>
wrote: > On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote: > > > Igniters, > > > > I've been working on the task that will let the user to retrieve version > > related information for a particular Cache.Entry object. > > All the details are here: > https://issues.apache.org/jira/browse/IGNITE-946 > > > > VersionedEntry of a given Cache.Entry can be retrieved by a call to > > 'Cache.Entry.unwrap(VersionedEntry.class)'. > > I've already fully supported 'unwrap' for Cache.Entry when it is returned > > from: > > - Cache.invoke(); > > - Cache.invokeAll(); > > - IgniteCache.randomEntry(); > > > > The following entry points are left: > > - Cache.iterator(); > > - IgniteCache.localEntries(). > > > > However, I doubt that it makes sense to support these two last methods. > > In my understanding a use case scenario of VersionedEntry is the > > following: the user get a VersionedEntry for a particular key(s) using > > Cache.invoke, keeps it and then compares with other VersionEntries for > the > > same key retrieved later. > > I don't think that the user will iterate over a cache using > > Cache.iterator() or IgniteCache.localEntries() in order to get a version, > > especially in production. > > > > Denis, what is the reason for not supporting a version on an entry at all > times? Is there a specific performance issue or slow down you are concerned > with? > > entry is stored and we never send it to client (for performance reasons obviously). For example, in continuous query you can acquire version in the remote filter, but not in local listener. > > > > > What do you think? Do you see any other real life scenarios I'm missing? > > > > -- > > Denis > > > |
On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: > On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]> > wrote: > >> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote: >> >>> Igniters, >>> >>> I've been working on the task that will let the user to retrieve version >>> related information for a particular Cache.Entry object. >>> All the details are here: >> https://issues.apache.org/jira/browse/IGNITE-946 >>> VersionedEntry of a given Cache.Entry can be retrieved by a call to >>> 'Cache.Entry.unwrap(VersionedEntry.class)'. >>> I've already fully supported 'unwrap' for Cache.Entry when it is returned >>> from: >>> - Cache.invoke(); >>> - Cache.invokeAll(); >>> - IgniteCache.randomEntry(); >>> >>> The following entry points are left: >>> - Cache.iterator(); >>> - IgniteCache.localEntries(). >>> >>> However, I doubt that it makes sense to support these two last methods. >>> In my understanding a use case scenario of VersionedEntry is the >>> following: the user get a VersionedEntry for a particular key(s) using >>> Cache.invoke, keeps it and then compares with other VersionEntries for >> the >>> same key retrieved later. >>> I don't think that the user will iterate over a cache using >>> Cache.iterator() or IgniteCache.localEntries() in order to get a version, >>> especially in production. >>> >> Denis, what is the reason for not supporting a version on an entry at all >> times? Is there a specific performance issue or slow down you are concerned >> with? >> >> > From my understanding, version is available only on the node where the > entry is stored and we never send it to client (for performance reasons > obviously). For example, in continuous query you can acquire version in the > remote filter, but not in local listener. > GridCacheQueryManager.scanIterator() that is, as I understand, is executed on every node and returns iterators containing keys and values. If we want to support VersionedEntry for Cache.iterator() then we need to: - transfer an entry version along with a key and value; - rework GridCacheQueryManager.scanIterator(); This will affect the performance cause we will start transferring more data. Plus, I doubt that the user will use Cache.iterator() in production to get an entry version. So I don't see any value by supporting VersionedEntry for Cache.iterator() and voting for not doing this. Objections, other opinions? -- Denis >>> What do you think? Do you see any other real life scenarios I'm missing? >>> >>> -- >>> Denis >>> |
On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda <[hidden email]> wrote:
> > > On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: > >> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email] >> > >> wrote: >> >> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote: >>> >>> Igniters, >>>> >>>> I've been working on the task that will let the user to retrieve version >>>> related information for a particular Cache.Entry object. >>>> All the details are here: >>>> >>> https://issues.apache.org/jira/browse/IGNITE-946 >>> >>>> VersionedEntry of a given Cache.Entry can be retrieved by a call to >>>> 'Cache.Entry.unwrap(VersionedEntry.class)'. >>>> I've already fully supported 'unwrap' for Cache.Entry when it is >>>> returned >>>> from: >>>> - Cache.invoke(); >>>> - Cache.invokeAll(); >>>> - IgniteCache.randomEntry(); >>>> >>>> The following entry points are left: >>>> - Cache.iterator(); >>>> - IgniteCache.localEntries(). >>>> >>>> However, I doubt that it makes sense to support these two last methods. >>>> In my understanding a use case scenario of VersionedEntry is the >>>> following: the user get a VersionedEntry for a particular key(s) using >>>> Cache.invoke, keeps it and then compares with other VersionEntries for >>>> >>> the >>> >>>> same key retrieved later. >>>> I don't think that the user will iterate over a cache using >>>> Cache.iterator() or IgniteCache.localEntries() in order to get a >>>> version, >>>> especially in production. >>>> >>>> Denis, what is the reason for not supporting a version on an entry at >>> all >>> times? Is there a specific performance issue or slow down you are >>> concerned >>> with? >>> >>> >>> From my understanding, version is available only on the node where the >> entry is stored and we never send it to client (for performance reasons >> obviously). For example, in continuous query you can acquire version in >> the >> remote filter, but not in local listener. >> >> Seems that you are correct. Cache.iterator() relies on > GridCacheQueryManager.scanIterator() that is, as I understand, is executed > on every node and returns iterators containing keys and values. > > If we want to support VersionedEntry for Cache.iterator() then we need to: > - transfer an entry version along with a key and value; > - rework GridCacheQueryManager.scanIterator(); > This will affect the performance cause we will start transferring more > data. Plus, I doubt that the user will use Cache.iterator() in production > to get an entry version. > So I don't see any value by supporting VersionedEntry for Cache.iterator() > and voting for not doing this. Objections, other opinions? > I agree about IgniteCache.iterator(), however I disagree about IgniteCache.localEntries(). Give that the latter method is local, we should always be able to provide the version, so why not do it? Btw, please don't forget to reflect this in the javadoc. > > -- > Denis > > What do you think? Do you see any other real life scenarios I'm missing? >>>> >>>> -- >>>> Denis >>>> >>>> > |
On 7/31/2015 10:26 AM, Dmitriy Setrakyan wrote: > On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda <[hidden email]> wrote: > >> >> On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: >> >>> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email] >>> wrote: >>> >>> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> wrote: >>>> Igniters, >>>>> I've been working on the task that will let the user to retrieve version >>>>> related information for a particular Cache.Entry object. >>>>> All the details are here: >>>>> >>>> https://issues.apache.org/jira/browse/IGNITE-946 >>>> >>>>> VersionedEntry of a given Cache.Entry can be retrieved by a call to >>>>> 'Cache.Entry.unwrap(VersionedEntry.class)'. >>>>> I've already fully supported 'unwrap' for Cache.Entry when it is >>>>> returned >>>>> from: >>>>> - Cache.invoke(); >>>>> - Cache.invokeAll(); >>>>> - IgniteCache.randomEntry(); >>>>> >>>>> The following entry points are left: >>>>> - Cache.iterator(); >>>>> - IgniteCache.localEntries(). >>>>> >>>>> However, I doubt that it makes sense to support these two last methods. >>>>> In my understanding a use case scenario of VersionedEntry is the >>>>> following: the user get a VersionedEntry for a particular key(s) using >>>>> Cache.invoke, keeps it and then compares with other VersionEntries for >>>>> >>>> the >>>> >>>>> same key retrieved later. >>>>> I don't think that the user will iterate over a cache using >>>>> Cache.iterator() or IgniteCache.localEntries() in order to get a >>>>> version, >>>>> especially in production. >>>>> >>>>> Denis, what is the reason for not supporting a version on an entry at >>>> all >>>> times? Is there a specific performance issue or slow down you are >>>> concerned >>>> with? >>>> >>>> >>>> From my understanding, version is available only on the node where the >>> entry is stored and we never send it to client (for performance reasons >>> obviously). For example, in continuous query you can acquire version in >>> the >>> remote filter, but not in local listener. >>> >>> Seems that you are correct. Cache.iterator() relies on >> GridCacheQueryManager.scanIterator() that is, as I understand, is executed >> on every node and returns iterators containing keys and values. >> >> If we want to support VersionedEntry for Cache.iterator() then we need to: >> - transfer an entry version along with a key and value; >> - rework GridCacheQueryManager.scanIterator(); > >> This will affect the performance cause we will start transferring more >> data. Plus, I doubt that the user will use Cache.iterator() in production >> to get an entry version. >> So I don't see any value by supporting VersionedEntry for Cache.iterator() >> and voting for not doing this. Objections, other opinions? >> > I agree about IgniteCache.iterator(), however I disagree about > IgniteCache.localEntries(). Give that the latter method is local, we should > always be able to provide the version, so why not do it? > > Btw, please don't forget to reflect this in the javadoc. supported it, there are some non trivial issues left with OFF_HEAP scenario. -- Denis > >> -- >> Denis >> >> What do you think? Do you see any other real life scenarios I'm missing? >>>>> -- >>>>> Denis >>>>> >>>>> |
Free forum by Nabble | Edit this page |