[
https://issues.apache.org/jira/browse/IGNITE-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16268179#comment-16268179
]
ASF GitHub Bot commented on IGNITE-5490:
----------------------------------------
GitHub user sunnychanwork opened a pull request:
https://github.com/apache/ignite/pull/3100
IGNITE-5490 Ignite Continuous Query might not send update request
During continuous query setup, there are potential updates in flight that
would potentially have a situation like this:
T1 updates E1, lsnrs!=null, obtain update counter 1
T2 updates E2, lsnrs==null, obtain update counter 2
T3 updates E3, lsnrs!=null, obtain update counter 3
Notice that as E1 E2 and E3 are different there are no locks and they can
proceed in parallel. As a result, the sequence of updates being sent to
CQManager will be 1,3 with 2 missing and it will wait for update 2 forever
which will never come.
To fix this I propose to use a ReadWrite lock to ensure that the Map Entry
update will complete before setting up new continuous query.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/sunnychanwork/ignite IGNITE-5960
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3100.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3100
----
commit 3cff5cf0ebc282c9300613e4d6726df5dd56ab60
Author: Sunny Chan, CLSA <[email protected]>
Date: 2017-11-28T05:52:14Z
IGNITE-5490 use a ReadWrite lock to ensure that the Map Entry update
will complete before setting up new continuous query
----
> Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
> -----------------------------------------------------------------------
>
> Key: IGNITE-5490
> URL: https://issues.apache.org/jira/browse/IGNITE-5490
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Affects Versions: 2.0
> Reporter: Ivan Rakov
>
> With new 2.0 architecture, many caches can share one memory policy. Memory
> metrics allows to measure memory usage (loaded pages) for the whole policy.
> However, there's also a need to measure how much memory (or pages) is used by
> each cache.
> Before 2.0 such information was accessible with
> CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0.
> We should either implement it or provide alternative metrics (e. g.
> approximate number of loaded pages per cache). Please note that if
> persistence is *disabled*, precise number of loaded pages per cache is not
> defined - one page can contain entries of different caches.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
