[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures

2016-03-01 Thread Konstantin Margorin (JIRA) 

[ 
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 {{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}


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

2016-03-01 Thread Konstantin Margorin (JIRA) 

[ 
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 {{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?
> 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

2016-02-21 Thread Konstantin Margorin (JIRA) 

 [ 
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.
> Map getAll(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

2016-02-19 Thread Konstantin Margorin (JIRA) 

 [ 
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

2016-02-14 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-12 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-12 Thread Konstantin Margorin (JIRA) 

 [ 
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

2016-02-11 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-10 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-10 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-10 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-10 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-10 Thread Konstantin Margorin (JIRA) 

[ 
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

2016-02-09 Thread Konstantin Margorin (JIRA) 

 [ 
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)