[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures
[ https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173717#comment-15173717 ] Konstantin Margorin edited comment on IGNITE-640 at 3/1/16 2:20 PM: Some thoughts about possible multimap implementation. According to above suggestion we shell use cache with specially constructed key: {code} class MultiKey { @CacheAffinityMapped private K key; int index; } {code} Method {{put(K key, V value)}} should created MultiKey for a new value. We should know new index value for MultiKey construction in the {{put}} method. The simplest implementation will use another {{CacheindexCache}} to keep count of items with key K. So, pseudo-code for put will look like {code} put(K key, V value) { try (Transaction tx = Ignition.ignite().transactions().txStart()) { newIndex = indexCache.get(key) + 1; indexCache.put(key, newIndex); multikeyCache.put(new MultiKey(key, newIndex), value); tx.commit() } } {code} The problem here is that we use: - {{transaction}} - one {{get}} - two {{put}} cache operations for one Multikey {{put}} operation. It looks like big overhead. Dmitriy suggested another way: {quote} An alternative way would be to store Key to List, i. e. to store Lists directly in cache. Then we can use EntryProcessor to add/remove elements to the list. The only problem here is that we will not be able to update the existing lists, but rather clone the lists, so we can add/remove elements to it, but I still think it will be cheaper than using transactions. {quote} was (Author: ruskim): Some thoughts possible multimap about implementation. According to above suggestion we shell use cache with specially constructed key: {code} class MultiKey { @CacheAffinityMapped private K key; int index; } {code} Method {{put(K key, V value)}} should created MultiKey for a new value. We should know new index value for MultiKey construction in the {{put}} method. The simplest implementation will use another {{Cache indexCache}} to keep count of items with key K. So, pseudo-code for put will look like {code} put(K key, V value) { try (Transaction tx = Ignition.ignite().transactions().txStart()) { newIndex = indexCache.get(key) + 1; indexCache.put(key, newIndex); multikeyCache.put(new MultiKey(key, newIndex), value); tx.commit() } } {code} The problem here is that we use: - {{transaction}} - one {{get}} - two {{put}} cache operations for one Multikey {{put}} operation. It looks like big overhead. Dmitriy suggested another way: {quote} An alternative way would be to store Key to List, i. e. to store Lists directly in cache. Then we can use EntryProcessor to add/remove elements to the list. The only problem here is that we will not be able to update the existing lists, but rather clone the lists, so we can add/remove elements to it, but I still think it will be cheaper than using transactions. {quote} > Implement IgniteMultimap data structures > > > Key: IGNITE-640 > URL: https://issues.apache.org/jira/browse/IGNITE-640 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Reporter: Dmitriy Setrakyan >Assignee: Konstantin Margorin > > We need to add {{IgniteMultimap}} data structure in addition to other data > structures provided by Ignite. {{IgniteMultiMap}} should have similar API to > {{java.util.Map}} class in JDK, but support the semantics of multiple values > per key, similar to [Guava > Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html]. > > However, unlike in Guava, our multi-map should work with Lists, not > Collections. Lists should make it possible to support the following methods: > {code} > // Gets value at a certain index for a key. > V get(K, index); > // Gets all values for a collection of keys at a certain index. > Map getAll(Collection, index); > // Gets values for specified indexes for a key. > List get(K, Iterable indexes); > // Gets all values for a collection of keys at specified indexes. > Map getAll(Collection, Iterable indexes); > // Gets values for specified range of indexes, between min and max. > List get(K, int min, int max); > // Gets all values for a collection of keys for a specified index range, > between min and max. > Map getAll(Collection, int min, int max); > // Gets all values for a specific key. > List get(K); > // Gets all values for a collection of keys. > Map getAll(Collection); > // Iterate through all elements with a certain index. > Iterator > iterate(int idx); > // Do we need this? >
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[ https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173717#comment-15173717 ] Konstantin Margorin commented on IGNITE-640: Some thoughts possible multimap about implementation. According to above suggestion we shell use cache with specially constructed key: {code} class MultiKey { @CacheAffinityMapped private K key; int index; } {code} Method {{put(K key, V value)}} should created MultiKey for a new value. We should know new index value for MultiKey construction in the {{put}} method. The simplest implementation will use another {{CacheindexCache}} to keep count of items with key K. So, pseudo-code for put will look like {code} put(K key, V value) { try (Transaction tx = Ignition.ignite().transactions().txStart()) { newIndex = indexCache.get(key) + 1; indexCache.put(key, newIndex); multikeyCache.put(new MultiKey(key, newIndex), value); tx.commit() } } {code} The problem here is that we use: - {{transaction}} - one {{get}} - two {{put}} cache operations for one Multikey {{put}} operation. It looks like big overhead. Dmitriy suggested another way: {quote} An alternative way would be to store Key to List, i. e. to store Lists directly in cache. Then we can use EntryProcessor to add/remove elements to the list. The only problem here is that we will not be able to update the existing lists, but rather clone the lists, so we can add/remove elements to it, but I still think it will be cheaper than using transactions. {quote} > Implement IgniteMultimap data structures > > > Key: IGNITE-640 > URL: https://issues.apache.org/jira/browse/IGNITE-640 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Reporter: Dmitriy Setrakyan >Assignee: Konstantin Margorin > > We need to add {{IgniteMultimap}} data structure in addition to other data > structures provided by Ignite. {{IgniteMultiMap}} should have similar API to > {{java.util.Map}} class in JDK, but support the semantics of multiple values > per key, similar to [Guava > Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html]. > > However, unlike in Guava, our multi-map should work with Lists, not > Collections. Lists should make it possible to support the following methods: > {code} > // Gets value at a certain index for a key. > V get(K, index); > // Gets all values for a collection of keys at a certain index. > Map getAll(Collection, index); > // Gets values for specified indexes for a key. > List get(K, Iterable indexes); > // Gets all values for a collection of keys at specified indexes. > Map getAll(Collection, Iterable indexes); > // Gets values for specified range of indexes, between min and max. > List get(K, int min, int max); > // Gets all values for a collection of keys for a specified index range, > between min and max. > Map getAll(Collection, int min, int max); > // Gets all values for a specific key. > List get(K); > // Gets all values for a collection of keys. > Map getAll(Collection); > // Iterate through all elements with a certain index. > Iterator > iterate(int idx); > // Do we need this? > Collection get(K, IgniteBiPredicate ) > {code} > Multimap should also support colocated and non-colocated modes, similar to > [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java] > and its implementation, > [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java]. > h2. Design Details > The most natural way to implement such map, would be to store every value > under a separate key in an Ignite cache. For example, let's say that we have > a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should > end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. > This means that we need to wrap user key into our own, internal key, which > will also have {{index}} field. > Also note that we need to collocate all the values for the same key on the > same node, which means that we need to define user key K as the affinity key, > like so: > {code} > class MultiKey { > @CacheAffinityMapped > private K key; > int index; > } > {code} > Look ups of values at specific indexes becomes very simple. Just attach a > specific index to a key and do a cache lookup. Look ups for all values for a > key should work as following: > {code} > MultiKey key; > V v = null; > int index = 0; > List res = new LinkedList<>();
[jira] [Assigned] (IGNITE-640) Implement IgniteMultimap data structures
[ https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Margorin reassigned IGNITE-640: -- Assignee: Konstantin Margorin > Implement IgniteMultimap data structures > > > Key: IGNITE-640 > URL: https://issues.apache.org/jira/browse/IGNITE-640 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Reporter: Dmitriy Setrakyan >Assignee: Konstantin Margorin > > We need to add {{IgniteMultimap}} data structure in addition to other data > structures provided by Ignite. {{IgniteMultiMap}} should have similar API to > {{java.util.Map}} class in JDK, but support the semantics of multiple values > per key, similar to [Guava > Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html]. > > However, unlike in Guava, our multi-map should work with Lists, not > Collections. Lists should make it possible to support the following methods: > {code} > // Gets value at a certain index for a key. > V get(K, index); > // Gets all values for a collection of keys at a certain index. > MapgetAll(Collection, index); > // Gets values for specified indexes for a key. > Collection get(K, Iterable indexes); > // Gets all values for a collection of keys at specified indexes. > Map getAll(Collection, Iterable indexes); > // Gets values for specified range of indexes, between min and max. > Collection get(K, int min, int max); > // Gets all values for a collection of keys for a specified index range, > between min and max. > Map getAll(Collection, int min, int max); > // Gets all values for a specific key. > Collection get(K); > // Gets all values for a collection of keys. > Map getAll(Collection); > Collection get(K, IgniteBiPredicate ) > {code} > Multimap should also support colocated and non-colocated modes, similar to > [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java] > and its implementation, > [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java]. > h2. Design Details > The most natural way to implement such map, would be to store every value > under a separate key in an Ignite cache. For example, let's say that we have > a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should > end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. > This means that we need to wrap user key into our own, internal key, which > will also have {{index}} field. > Also note that we need to collocate all the values for the same key on the > same node, which means that we need to define user key K as the affinity key, > like so: > {code} > class MultiKey { > @CacheAffinityMapped > private K key; > int index; > } > {code} > Look ups of values at specific indexes becomes very simple. Just attach a > specific index to a key and do a cache lookup. Look ups for all values for a > key should work as following: > {code} > MultiKey key; > V v = null; > int index = 0; > List res = new LinkedList<>(); > do { > v = cache.get(MultiKey(K, index)); > if (v != null) > res.add(v); > index++; > } > while (v != null); > return res; > {code} > We could also use batching for performance reason. In this case the batch > size should be configurable. > {code} > int index = 0; > List res = new LinkedList<>(); > while (true) { > List batch = new ArrayList<>(batchSize); > // Populate batch. > for (; index < batchSize; index++) > batch.add(new MultiKey(K, index % batchSize); > Map batchRes = cache.getAll(batch); > // Potentially need to properly sort values, based on the key order, > // if the returning map does not do it automatically. > res.addAll(batchRes.values()); > if (res.size() < batch.size()) > break; > } > return res; > {code} > h2. Evictions > Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of > keys, and maximum number of values for a key. The maximum number of keys > should be controlled by Ignite standard eviction policy. The maximum number > of values for a key should be controlled by the implementation of the > multi-map. Either eviction parameter should be configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2650) Ignite should throw an exception on start of dynamic cache with swap if Ignite uses NoopSwapSpaceSpi
[ https://issues.apache.org/jira/browse/IGNITE-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Margorin reassigned IGNITE-2650: --- Assignee: Konstantin Margorin > Ignite should throw an exception on start of dynamic cache with swap if > Ignite uses NoopSwapSpaceSpi > > > Key: IGNITE-2650 > URL: https://issues.apache.org/jira/browse/IGNITE-2650 > Project: Ignite > Issue Type: Bug >Reporter: Artem Shutak >Assignee: Konstantin Margorin > Labels: newbie > Fix For: 1.6 > > > Ignite should throw an exception on start of dynamic cache with enabled swap > if Ignite uses NoopSwapSpaceSpi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap
[ https://issues.apache.org/jira/browse/IGNITE-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146622#comment-15146622 ] Konstantin Margorin commented on IGNITE-1783: - Hello. Just want to clarify if replacing GridBoundedConcurrentLinkedHashMap with ConcurrentLinkedHashMap really required. It's true that GridBoundedConcurrentLinkedHashMap is the same as ConcurrentLinkedHashMap, but with different order of constructor arguments. The value of this order is possibility to reduce number of arguments of constructor in some cases. Currently there are 5 places in code, where constructor takes only one or two arguments. If ConcurrentLinkedHashMap will be used in these places, each constructor will require 4 arguments. For example instead of: new GridBoundedConcurrentLinkedHashMap<>(MAX_PATH_CACHE); there will be: new ConcurrentLinkedHashMap<>(DFLT_INIT_CAP, DFLT_LOAD_FACTOR, DFLT_CONCUR_LVL, MAX_PATH_CACHE); Here the list of all such places: \org\apache\ignite\internal\processors\query\h2\IgniteH2Indexing.java private final GridBoundedConcurrentLinkedHashMap, TwoStepCachedQuery> twoStepCache = new GridBoundedConcurrentLinkedHashMap<>(TWO_STEP_QRY_CACHE_SIZE); \org\apache\ignite\internal\processors\igfs\IgfsModeResolver.java modesCache = new GridBoundedConcurrentLinkedHashMap<>(MAX_PATH_CACHE); childrenModesCache = new GridBoundedConcurrentLinkedHashMap<>(MAX_PATH_CACHE); \org\apache\ignite\internal\util\GridReflectionCache.java private ConcurrentMap fields = new GridBoundedConcurrentLinkedHashMap<>(CACHE_SIZE, CACHE_SIZE); private ConcurrentMap mtds = new GridBoundedConcurrentLinkedHashMap<>(CACHE_SIZE, CACHE_SIZE); So, the question - does replacement really make sense? > Remove GridBoundedConcurrentLinkedHashMap and replace its usages with > ConcurrentLinkedHashMap > - > > Key: IGNITE-1783 > URL: https://issues.apache.org/jira/browse/IGNITE-1783 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Konstantin Margorin >Priority: Trivial > Labels: newbie > > From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the > only difference from {{ConcurrentLinkedHashMap}} is in order of constructor > arguments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap
[ https://issues.apache.org/jira/browse/IGNITE-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144264#comment-15144264 ] Konstantin Margorin commented on IGNITE-1783: - Hi. Should GridBoundedConcurrentLinkedHashMap be removed completely, including class implementation and test? > Remove GridBoundedConcurrentLinkedHashMap and replace its usages with > ConcurrentLinkedHashMap > - > > Key: IGNITE-1783 > URL: https://issues.apache.org/jira/browse/IGNITE-1783 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Konstantin Margorin >Priority: Trivial > Labels: newbie > > From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the > only difference from {{ConcurrentLinkedHashMap}} is in order of constructor > arguments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap
[ https://issues.apache.org/jira/browse/IGNITE-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Margorin reassigned IGNITE-1783: --- Assignee: Konstantin Margorin > Remove GridBoundedConcurrentLinkedHashMap and replace its usages with > ConcurrentLinkedHashMap > - > > Key: IGNITE-1783 > URL: https://issues.apache.org/jira/browse/IGNITE-1783 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Konstantin Margorin >Priority: Trivial > Labels: newbie > > From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the > only difference from {{ConcurrentLinkedHashMap}} is in order of constructor > arguments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15142534#comment-15142534 ] Konstantin Margorin commented on IGNITE-2555: - Hi Anton. I updated the test and included it to IgniteBasicTestSuite. Ignite Basic tests passed: http://204.14.53.151/viewLog.html?buildId=112610=buildChangesDiv=IgniteTests_IgniteBasic But looks like I could not run "Run Cache" tash with my patch - there is no option to select my patch there. > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141036#comment-15141036 ] Konstantin Margorin commented on IGNITE-2555: - Anton, I added test for checking local node metrics logging. Should I add it to any test suite? > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141060#comment-15141060 ] Konstantin Margorin commented on IGNITE-2555: - Looks like collision :) My test is already in pull request. > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141060#comment-15141060 ] Konstantin Margorin edited comment on IGNITE-2555 at 2/10/16 4:07 PM: -- Looks like collision :) My test is already in pull request. I'll add cache put/get to check that nodes alive. was (Author: ruskim): Looks like collision :) My test is already in pull request. > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141036#comment-15141036 ] Konstantin Margorin edited comment on IGNITE-2555 at 2/10/16 4:03 PM: -- Anton, I added test for checking local node metrics logging. Should I add it to any test suite? Actually my changes could be not covered by other test suites, because by default local metric logging invoked only 60 sec after node startup. My test guarantee the code execution. was (Author: ruskim): Anton, I added test for checking local node metrics logging. Should I add it to any test suite? > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140571#comment-15140571 ] Konstantin Margorin commented on IGNITE-2555: - Anton, thank you for explanation. License & Javadoc tests passed at TeamCity: http://204.14.53.151/viewType.html?buildTypeId=IgniteTests_RatJavadoc_IgniteTests=pull%2F468%2Fmerge=buildTypeStatusDiv Looks like there are no other test suites affected by my patch. What I need to do more, to complete the task? > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2555) Include offheap usage in metrics report
[ https://issues.apache.org/jira/browse/IGNITE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Margorin reassigned IGNITE-2555: --- Assignee: Konstantin Margorin > Include offheap usage in metrics report > --- > > Key: IGNITE-2555 > URL: https://issues.apache.org/jira/browse/IGNITE-2555 > Project: Ignite > Issue Type: Task >Affects Versions: 1.5.0.final >Reporter: Sergey Kozlov >Assignee: Konstantin Margorin >Priority: Minor > Labels: newbie > > The local node prints out the set of key parameters in its log (or console). > It makes sense to add offheap usage (used/free/committed) to that report. > {noformat} > Metrics for local node (to disable set 'metricsLogFrequency' to 0) > ^-- Node [id=41b12e0f, name=null] > ^-- H/N/C [hosts=1, nodes=14, CPUs=8] > ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%] > ^-- Heap [used=1364MB, free=27,44%, comm=1881MB] > ^-- Public thread pool [active=0, idle=16, qSize=0] > ^-- System thread pool [active=1, idle=15, qSize=0] > ^-- Outbound messages queue [size=0] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)