date:20171017


[ 
https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619
 ] 

Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 10:06 AM:
-

The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 ({color:#d04437}-5%{color}) |  782.23 
({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 
({color:#d04437}-1%{color}) |
| JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 
({color:#d04437}-5%{color}) |  94.90 ({color:#d04437}-11%{color}) | 0.886 
({color:#d04437}-5%{color}) |

The parameters {{pageSize}} and {{fetchSize}} are default (1024).


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 ({color:#d04437}-5%{color}) |  782.23 
({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 
({color:#d04437}-1%{color}) |
| JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 
({color:#d04437}-5%{color}) |  94.90 ({color:#d04437}-11%{color}) | 0.886 
({color:#d04437}-5%{color}) |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-17 Thread Denis Mekhanikov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207556#comment-16207556
 ] 

Denis Mekhanikov commented on IGNITE-6572:
--

[~vozerov]
All calls to registerCache, unregisterCache and registerType of 
IgniteH2Indexing class are performed under the same mutex in 
GridQueryProcessor. So there is no need to make this logic thread-safe, as it 
is never performed concurrently.

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution


[ 
https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619
 ] 

Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 10:03 AM:
-

The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 ({color:#d04437}-5%{color}) |  782.23 
({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 
({color:#d04437}-1%{color}) |
| JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 
({color:#d04437}-5%{color}) |  94.90 ({color:#d04437}-11%{color}) | 0.886 
({color:#d04437}-5%{color}) |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 |  782.23 | 105.27| 0.919 |
| JDBC thin | 4367.87 | 673.16 |  94.90 | 0.886 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5839) Unclear exception from BinaryObjectBuilder::build call when builder is reused


[ 
https://issues.apache.org/jira/browse/IGNITE-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207258#comment-16207258
 ] 

ASF GitHub Bot commented on IGNITE-5839:


Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2532


> Unclear exception from BinaryObjectBuilder::build call when builder is reused
> -
>
> Key: IGNITE-5839
> URL: https://issues.apache.org/jira/browse/IGNITE-5839
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Andrew Mashenkov
> Fix For: 2.3
>
>
> Simple test where {{BinaryObjectBuilder}} builder object is reused fails with 
> exception {noformat}org.apache.ignite.binary.BinaryObjectException: Wrong 
> value has been set [typeName=SimpleCls, fieldName=str, fieldType=String, 
> assignedValueType=Object]{noformat}
> {noformat}
> IgniteCache cache = /* obtain a reference to 
> withKeepBinary cache instance */;
> BinaryObjectBuilder bldr = grid(0).binary().builder("SimpleCls");
> bldr.setField("str", "abc");
> c.put(0, bldr.build());
> bldr.setField("str", null);
> c.put(1, bldr.build());
> bldr.setField("str", "def");
> c.put(2, bldr.build()); //exception will be thrown by call 
> bldr.build()
> {noformat}
> It can be fixed by simply recreating BinaryObjectBuilder instead of reusing 
> the same instance. 
> However reusing builder object must be either explicitly prohibited or 
> exception must be fixed.
> Right now documentation on builder class says nothing about reusing this 
> object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-17 Thread Vladimir Ozerov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207536#comment-16207536
 ] 

Vladimir Ozerov commented on IGNITE-6572:
-

PR: https://github.com/apache/ignite/pull/2850

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6648) ML javadoc is missing in 2.2 binary release

2017-10-17 Thread Anton Vinogradov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Vinogradov resolved IGNITE-6648.
--
Resolution: Fixed

Merged to 2.3 and master. 
Thanks for contribution.

> ML javadoc is missing in 2.2 binary release   
> 
>
> Key: IGNITE-6648
> URL: https://issues.apache.org/jira/browse/IGNITE-6648
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Critical
> Fix For: 2.3
>
>
> ML javadoc is missing in binary releases. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5593) Affinity change message leak on massive topology updates


[ 
https://issues.apache.org/jira/browse/IGNITE-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207261#comment-16207261
 ] 

ASF GitHub Bot commented on IGNITE-5593:


Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2210


> Affinity change message leak on massive topology updates
> 
>
> Key: IGNITE-5593
> URL: https://issues.apache.org/jira/browse/IGNITE-5593
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.1
>
>
> When late affinity assignment is enabled, we complete the exchange future 
> with custom discovery event. Since discovery topology events usually are much 
> faster than exchange futures completion, it is possible that a newly joined 
> node can 'see' the affinity change messages that are related to previous 
> topology versions when this node even was not present in the topology.
> When this message is received, an exchange future is created and this message 
> is added to discoEvts list. However, this future never completes on this node 
> because init() is never called. This means that this exchange future sits in 
> the exchange set with the affinity change message.
> Since the number of topology changes (and, thus, messages) can be quite 
> large, this leads to excessive memory consumption on the starting node. I've 
> observed ~3Gb of heap wasted on one of the nodes when > 200 nodes were 
> restarted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6648) ML javadoc is missing in 2.2 binary release


 [ 
https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ostanin updated IGNITE-6648:
-
Fix Version/s: 2.3

> ML javadoc is missing in 2.2 binary release   
> 
>
> Key: IGNITE-6648
> URL: https://issues.apache.org/jira/browse/IGNITE-6648
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> ML javadoc is missing in binary releases. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6648) ML javadoc is missing in 2.2 binary release

Oleg Ostanin created IGNITE-6648:


 Summary: ML javadoc is missing in 2.2 binary release   
 Key: IGNITE-6648
 URL: https://issues.apache.org/jira/browse/IGNITE-6648
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


ML javadoc is missing in binary releases.   




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6648) ML javadoc is missing in 2.2 binary release


 [ 
https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ostanin updated IGNITE-6648:
-
Priority: Critical  (was: Major)

> ML javadoc is missing in 2.2 binary release   
> 
>
> Key: IGNITE-6648
> URL: https://issues.apache.org/jira/browse/IGNITE-6648
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Critical
> Fix For: 2.3
>
>
> ML javadoc is missing in binary releases. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration

2017-10-17 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6647:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

> Web Console: Implement schema migration
> ---
>
> Key: IGNITE-6647
> URL: https://issues.apache.org/jira/browse/IGNITE-6647
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.4
>
>
> We need to support schema updates for Web Console new versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration

2017-10-17 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6647:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

Please review.

> Web Console: Implement schema migration
> ---
>
> Key: IGNITE-6647
> URL: https://issues.apache.org/jira/browse/IGNITE-6647
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.4
>
>
> We need to support schema updates for Web Console new versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration

2017-10-17 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-6647:


Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: Implement schema migration
> ---
>
> Key: IGNITE-6647
> URL: https://issues.apache.org/jira/browse/IGNITE-6647
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> We need to support schema updates for Web Console new versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-17 Thread Pavel Tupitsyn (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207528#comment-16207528
 ] 

Pavel Tupitsyn commented on IGNITE-6627:


Looks good to me. Merged to master: 
{{93bf555a98c472ff7028a641b32ef5d8ba8df7cd}}.
Great job, [~alexey.tank2].

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum


[ 
https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207529#comment-16207529
 ] 

ASF GitHub Bot commented on IGNITE-6627:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2864


> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
> Fix For: 2.4
>
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6648) ML javadoc is missing in 2.2 binary release


[ 
https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207553#comment-16207553
 ] 

Oleg Ostanin commented on IGNITE-6648:
--

[~avinogradov]

Please review the changes:
https://github.com/apache/ignite/pull/2868

Here is the example build:
https://ci.ignite.apache.org/viewLog.html?buildId=894883=artifacts=IgniteRelease_XxxFromMirrorIgniteRelease3PrepareVote#!1rrb2,-wpvx2aopzexz,-1wknai9u1u6n4,1oz6l8xp9zo0n,-14amd5eyzzgpi,-1i6ixr10ypdh6

> ML javadoc is missing in 2.2 binary release   
> 
>
> Key: IGNITE-6648
> URL: https://issues.apache.org/jira/browse/IGNITE-6648
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>Priority: Critical
> Fix For: 2.3
>
>
> ML javadoc is missing in binary releases. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution


[ 
https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619
 ] 

Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 9:55 AM:


The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 |  782.23 | 105.27| 0.919 |
| JDBC thin | 4367.87 | 673.16 |  94.90 | 0.886 |


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||
| Nativa SQL | 9385.99 |
| JDBC v2 | .48 |  
| JDBC thin | 4367.87 |

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3840) Continue investigation: High memory utilization when OFFHEAP_TIERED mode and expiry policy are enabled.


[ 
https://issues.apache.org/jira/browse/IGNITE-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207268#comment-16207268
 ] 

ASF GitHub Bot commented on IGNITE-3840:


Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/1037


> Continue investigation: High memory utilization when OFFHEAP_TIERED mode and 
> expiry policy are enabled.
> ---
>
> Key: IGNITE-3840
> URL: https://issues.apache.org/jira/browse/IGNITE-3840
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Andrew Mashenkov
>Priority: Critical
>  Labels: community, important
> Fix For: 2.0
>
> Attachments: IgniteExpiryIssue.java, config.xml
>
>
> Continue investigation of high memory utilization.
> The problem is originally reported by Neil Wightman: 
> http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-cache-using-lots-of-heap-memory-td3414.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-17 Thread Vladimir Ozerov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207545#comment-16207545
 ] 

Vladimir Ozerov commented on IGNITE-6572:
-

[~dmekhanikov],
I did a review. Implementation is not thread-safe. Please wrap the schema 
register/unregister logic into a critical section.

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.


[ 
https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207684#comment-16207684
 ] 

ASF GitHub Bot commented on IGNITE-5195:


GitHub user ilantukh opened a pull request:

https://github.com/apache/ignite/pull/2872

IGNITE-5195 : DataStreamer remap optimization.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-5195

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2872.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 #2872


commit caa7f7c833a162a01edacb241634515cdce67ec2
Author: Ilya Lantukh 
Date:   2017-10-16T14:56:18Z

ignite-5195 : DataStreamer remap optimization.

commit 68b13fa248393c8ab75686c2956e84a2c5177839
Author: Ilya Lantukh 
Date:   2017-10-16T15:03:48Z

ignite-5195 : Added test.

commit e35b2d6508bd8b96c10d245253e066cdc2839a01
Author: Ilya Lantukh 
Date:   2017-10-17T13:50:53Z

ignite-5195 : Fixed failing tests, simplified solution.




> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

2017-10-17 Thread Ilya Lantukh (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh reassigned IGNITE-5195:


Assignee: Ilya Lantukh  (was: Anton Vinogradov)

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Ilya Lantukh
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment


[ 
https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707
 ] 

Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:30 PM:


This is not a bug, this is a [IGNITE-5846] (not implemented yet)


was (Author: zaleslaw):
This is not a bug, this is a 
[https://issues.apache.org/jira/browse/IGNITE-5846] (not implemented yet)

> Adapt Linear regression for distributed environment
> ---
>
> Key: IGNITE-6222
> URL: https://issues.apache.org/jira/browse/IGNITE-6222
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> Currently our implementation of linear regression works only locally which is 
> useless. So we need fix this implementation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment


[ 
https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707
 ] 

Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:30 PM:


This is not a bug, this is a 
[https://issues.apache.org/jira/browse/IGNITE-5846] (not implemented yet)


was (Author: zaleslaw):
This is not a bug, this is a feature (not implemented yet)

> Adapt Linear regression for distributed environment
> ---
>
> Key: IGNITE-6222
> URL: https://issues.apache.org/jira/browse/IGNITE-6222
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> Currently our implementation of linear regression works only locally which is 
> useless. So we need fix this implementation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5850) Introduce an API for baseline topology for persistence-enabled clusters


 [ 
https://issues.apache.org/jira/browse/IGNITE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-5850:
---
Labels: IEP-4  (was: )

> Introduce an API for baseline topology for persistence-enabled clusters
> ---
>
> Key: IGNITE-5850
> URL: https://issues.apache.org/jira/browse/IGNITE-5850
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>  Labels: IEP-4
> Fix For: 2.4
>
>
> Since the persistence was introduced, we require that cluster be started in 
> an inactive mode and activation happens only manually.
> We need to add a concept of baseline topology which is fixed on the first 
> cluster activation and may be changed later by a user. We need to develop a 
> consistent API facade for this purpose.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5854) Validate baseline topology change history during node joins


 [ 
https://issues.apache.org/jira/browse/IGNITE-5854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-5854:
---
Labels: IEP-4  (was: )

> Validate baseline topology change history during node joins
> ---
>
> Key: IGNITE-5854
> URL: https://issues.apache.org/jira/browse/IGNITE-5854
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>  Labels: IEP-4
> Fix For: 2.4
>
>
> It is possible to have a cluster-split restarts when persistence enabled:
> Start 1, 2, 3, 4, update data. Stop
> Start 1, 2. Update data. Stop
> Start 3, 4. Update data. Stop.
> Start 1, 2, 3, 4. Stop
> We need to make sure that the second start is not allowed. This can be done 
> by introducing baseline topology history and topology hash generation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5851) Automatically activate cluster if baseline topology is reached


 [ 
https://issues.apache.org/jira/browse/IGNITE-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-5851:
---
Labels: IEP-4  (was: )

> Automatically activate cluster if baseline topology is reached
> --
>
> Key: IGNITE-5851
> URL: https://issues.apache.org/jira/browse/IGNITE-5851
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>  Labels: IEP-4
> Fix For: 2.4
>
>
> When we have an API for baseline topology management, we can automatically 
> activate the cluster once all the nodes from the baseline topology are 
> started.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6651) Baseline includes attributes required for affinity function


 [ 
https://issues.apache.org/jira/browse/IGNITE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6651:
---
Summary: Baseline includes attributes required for affinity function  (was: 
Baseline includes only attributes required for affinity function)

> Baseline includes attributes required for affinity function
> ---
>
> Key: IGNITE-6651
> URL: https://issues.apache.org/jira/browse/IGNITE-6651
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Sergey Puchnin
>  Labels: IEP-4
>
> We need to design and implement an effective baseline topology format for 
> metastore so that metastore does not grow too fast.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6651) Baseline includes only attributes required for affinity function

Sergey Puchnin created IGNITE-6651:
--

 Summary: Baseline includes only attributes required for affinity 
function
 Key: IGNITE-6651
 URL: https://issues.apache.org/jira/browse/IGNITE-6651
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.3
Reporter: Sergey Puchnin


We need to design and implement an effective baseline topology format for 
metastore so that metastore does not grow too fast.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up


 [ 
https://issues.apache.org/jira/browse/IGNITE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6652:
---
Description: As an another point of validation   (was: Baseline should save 
attributes for AF to metasore)

> Gracefully deny joins of nodes with older version when baseline topology is 
> set up
> --
>
> Key: IGNITE-6652
> URL: https://issues.apache.org/jira/browse/IGNITE-6652
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Sergey Puchnin
>  Labels: IEP-4
>
> As an another point of validation 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6222) Adapt Linear regression for distributed environment


 [ 
https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Zinoviev resolved IGNITE-6222.
--
Resolution: Duplicate

This is not a bug, this is a feature (not implemented yet)

> Adapt Linear regression for distributed environment
> ---
>
> Key: IGNITE-6222
> URL: https://issues.apache.org/jira/browse/IGNITE-6222
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> Currently our implementation of linear regression works only locally which is 
> useless. So we need fix this implementation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment


[ 
https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707
 ] 

Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:29 PM:


This is not a bug, this is a feature (not implemented yet)


was (Author: zaleslaw):
This is not a bug, this is a feature (not implemented yet)

> Adapt Linear regression for distributed environment
> ---
>
> Key: IGNITE-6222
> URL: https://issues.apache.org/jira/browse/IGNITE-6222
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> Currently our implementation of linear regression works only locally which is 
> useless. So we need fix this implementation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5853) Provide a way to determine which user attributes are used in affinity calculation


 [ 
https://issues.apache.org/jira/browse/IGNITE-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-5853:
---
Labels: IEP-4  (was: )

> Provide a way to determine which user attributes are used in affinity 
> calculation
> -
>
> Key: IGNITE-5853
> URL: https://issues.apache.org/jira/browse/IGNITE-5853
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>  Labels: IEP-4
> Fix For: 2.4
>
>
> Since an affinity function may use user attributes to calculate affinity 
> distribution, we need to save these attributes to the metastore. However, 
> storing all the attributes is not very effective, so we need to have a way to 
> determine which attributes should be stored.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology


 [ 
https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-5852:
---
Labels: IEP-4  (was: )

> Cache affinity should be calculated wrt baseline topology
> -
>
> Key: IGNITE-5852
> URL: https://issues.apache.org/jira/browse/IGNITE-5852
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>  Labels: IEP-4
> Fix For: 2.4
>
>
> After we have an API for baseline topology management, we need to provide a 
> way to operate when real topology differs from the baseline. To facilitate 
> this, we need to calculate the affinity on the set of nodes which is an 
> intersection of the baseline topology and current topology



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6651) Baseline includes attributes required for affinity function


 [ 
https://issues.apache.org/jira/browse/IGNITE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6651:
---
Description: Baseline should save attributes for AF to metasore  (was: We 
need to design and implement an effective baseline topology format for 
metastore so that metastore does not grow too fast.)

> Baseline includes attributes required for affinity function
> ---
>
> Key: IGNITE-6651
> URL: https://issues.apache.org/jira/browse/IGNITE-6651
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Sergey Puchnin
>  Labels: IEP-4
>
> Baseline should save attributes for AF to metasore



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up

Sergey Puchnin created IGNITE-6652:
--

 Summary: Gracefully deny joins of nodes with older version when 
baseline topology is set up
 Key: IGNITE-6652
 URL: https://issues.apache.org/jira/browse/IGNITE-6652
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.3
Reporter: Sergey Puchnin


Baseline should save attributes for AF to metasore



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up


 [ 
https://issues.apache.org/jira/browse/IGNITE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6652:
---
Description: As another point of validation need to avoid join old version 
nodes  (was: As an another point of validation )

> Gracefully deny joins of nodes with older version when baseline topology is 
> set up
> --
>
> Key: IGNITE-6652
> URL: https://issues.apache.org/jira/browse/IGNITE-6652
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Sergey Puchnin
>  Labels: IEP-4
>
> As another point of validation need to avoid join old version nodes



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects


[ 
https://issues.apache.org/jira/browse/IGNITE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207599#comment-16207599
 ] 

ASF GitHub Bot commented on IGNITE-2766:


GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/2870

IGNITE-2766 Deterministically reopen cache after client reconnect.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-2766ex

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2870.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 #2870


commit 843566b74b3afdf78d3ede1a46adc927878c89e2
Author: Ilya Kasnacheev 
Date:   2017-10-17T12:53:05Z

IGNITE-2766 Deterministically reopen cache after client reconnect bis.




> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.


[ 
https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207600#comment-16207600
 ] 

Andrew Mashenkov commented on IGNITE-6649:
--

Todo: 
1. add eviction policy factory methods to IgniteConfiguration.
2. deprecate setEvictionPolicy method and update javadoc.
3. create a ticket for old method discontinuation in next major release.

> Add EvictionPolicy factory support in IgniteConfiguration.
> --
>
> Key: IGNITE-6649
> URL: https://issues.apache.org/jira/browse/IGNITE-6649
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Andrew Mashenkov
> Fix For: 2.4
>
>
> For now the only way to set EvictionPolicy to IgniteConfiguration is to use 
> EvictionPolicy instance. 
> That looks error prone as user can easily share instance between caches or 
> cache reincarnations and got unexpected results.
> E.g. it can cause an AssertionError if EvictionPolicy is reused.
> Steps to reproduce.
> 1. Create CacheConfiguration object that will be reused.
> 2. Create and fill a cache.
> 3. Destroy cache and create cache again with same CacheConfiguration object.
> 4. One of next put can fails with stacktrace below.
> The error is throws when EvictionPolicy tries to evict entries from cache 
> that has just been destroyed.
> Also, EvictionPolicy object can be implicitly holds by some user objects 
> (together with IgniteConfiguration) that can cause memory leak.
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

2017-10-17 Thread Andrey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Kuznetsov reassigned IGNITE-5553:


Assignee: Andrey Kuznetsov

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6650) Introduce effective storage format for baseline topology


 [ 
https://issues.apache.org/jira/browse/IGNITE-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6650:
---
Labels: IEP-4  (was: )

> Introduce effective storage format for baseline topology
> 
>
> Key: IGNITE-6650
> URL: https://issues.apache.org/jira/browse/IGNITE-6650
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>  Labels: IEP-4
>
> We need to design and implement an effective baseline topology format for 
> metastore so that metastore does not grow too fast.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution


[ 
https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619
 ] 

Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 12:32 PM:
-

The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 ({color:#d04437}-5%{color}) |  782.23 
({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 
({color:#d04437}-1%{color}) |
| JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 
({color:#d04437}-25%{color}) |  94.90 ({color:#d04437}-11%{color}) | 0.886 
({color:#d04437}-5%{color}) |

The parameters {{pageSize}} and {{fetchSize}} are default (1024).


was (Author: tledkov-gridgain):
The other benchmark result.

Configurations:
# Native SQL: 1 server, 1 client. SQL queries are execute4d on client on 
separate host
# JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host.
# JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and 
connects to the client node. SQL queries are executed on JDBC client on 
separate4 host.

SQL query:
{{SELECT val FROM test WHERE id = }}
where TEST table contains two columns: {{id long, val long}}
The table contains 1M unique rows.

|| Benchmark || Ops /sec (1 row) ||  Ops/sec (1000 rows) || Ops / sec (1 
rows) || Ops / sec (1M rows) ||
| Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 |
| JDBC v2 | .48 ({color:#d04437}-5%{color}) |  782.23 
({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 
({color:#d04437}-1%{color}) |
| JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 
({color:#d04437}-5%{color}) |  94.90 ({color:#d04437}-11%{color}) | 0.886 
({color:#d04437}-5%{color}) |

The parameters {{pageSize}} and {{fetchSize}} are default (1024).

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6649) Add EvitionPolicy factory support in IgniteConfiguration.

Andrew Mashenkov created IGNITE-6649:


 Summary: Add EvitionPolicy factory support in IgniteConfiguration.
 Key: IGNITE-6649
 URL: https://issues.apache.org/jira/browse/IGNITE-6649
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: cache
Reporter: Andrew Mashenkov
 Fix For: 2.4


For now the only way to set EvictionPolicy to IgniteConfiguration is to use 
EvictionPolicy instance. 
That looks error prone as user can easily share instance between caches or 
cache reincarnations and got unexpected results.

E.g. it can cause an AssertionError if EvictionPolicy is reused.
Steps to reproduce.

1. Create CacheConfiguration object that will be reused.
2. Create and fill a cache.
3. Destroy cache and create cache again with same CacheConfiguration object.
4. One of next put can fails with stacktrace below.

The error is throws when EvictionPolicy tries to evict entries from cache that 
has just been destroyed.

java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71)
at 
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275)
at 
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250)
at 
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161)
at 
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393)
at 
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
 




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.


 [ 
https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov reassigned IGNITE-6649:


Assignee: Andrew Mashenkov

> Add EvictionPolicy factory support in IgniteConfiguration.
> --
>
> Key: IGNITE-6649
> URL: https://issues.apache.org/jira/browse/IGNITE-6649
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.4
>
>
> For now the only way to set EvictionPolicy to IgniteConfiguration is to use 
> EvictionPolicy instance. 
> That looks error prone as user can easily share instance between caches or 
> cache reincarnations and got unexpected results.
> E.g. it can cause an AssertionError if EvictionPolicy is reused.
> Steps to reproduce.
> 1. Create CacheConfiguration object that will be reused.
> 2. Create and fill a cache.
> 3. Destroy cache and create cache again with same CacheConfiguration object.
> 4. One of next put can fails with stacktrace below.
> The error is throws when EvictionPolicy tries to evict entries from cache 
> that has just been destroyed.
> Also, EvictionPolicy object can be implicitly holds by some user objects 
> (together with IgniteConfiguration) that can cause memory leak.
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT


 [ 
https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6638:
---
Labels: IEP-4  (was: )

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
>  Labels: IEP-4
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6320) SQL: ANTLR performance assessment

2017-10-17 Thread Sergey Kalashnikov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207666#comment-16207666
 ] 

Sergey Kalashnikov commented on IGNITE-6320:


I've made some benchmarking with parsers generated by ANTLR with MySQL and P/L 
SQL grammars versus H2 prepared statement.
Also included the ANTLR based parser prototype I created earlier for 
.

The measurements for ANTLR parsers were made with two stage parsing strategy 
(SLL prediction mode).

Here are the results:

||Benchmark||ops/s||
|Complex Query ANTLR/MySQL Grammar|7830,615|
|Complex Query ANTLR/MySQL(Lexer only)|53441,816|
|Complex Query ANTLR/PL-SQL Grammar|3310,900|
|Complex Query H2|25368,322|
|Simple Query ANTLR/MySQL Grammar|28813,159|
|Simple Query ANTLR/PL-SQL Grammar|12581,615|
|Simple Query H2|118872,767|
|Trivial Query ANTLR/MySQL Grammar|120041,528|
|Trivial Query ANTLR/PL-SQL Grammar|63138,856|
|Trivial Query H2|546905,758|
|Drop index ANTLR/MySQL Grammar|350599,019|
|Drop index H2|2373889,332|
|Drop index ANTLR/IgniteProto|474410,677|
|Drop index JFLEX+BYACC/IgniteProto|389347,251|
|Batched Queries 1 Thread ANTLR/MySQL|35,256|
|Batched Queries 2 Threads ANTLR/MySQL|60,010|
|Batched Queries 4 Threads ANTLR/MySQL|95,171|
|Batched Queries 8 Threads ANLR/MySQL|135,311|

It looks like ANTLR parser doesn't scale well enough in multi-threaded 
environment, although single thread performance is good.



> SQL: ANTLR performance assessment
> -
>
> Key: IGNITE-6320
> URL: https://issues.apache.org/jira/browse/IGNITE-6320
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Fix For: 2.4
>
>
> Proposed process:
> 1) Download MySQL grammar [1]
> 2) Generate parser
> 3) Measure parsing performance for both simple and complex SQL queries with 
> JMH.
> 4) Analyze the numbers
> [1] https://github.com/antlr/grammars-v4/tree/master/mysql



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

2017-10-17 Thread Ilya Lantukh (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh reassigned IGNITE-5195:


Assignee: Anton Vinogradov

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6649) Add EvitionPolicy factory support in IgniteConfiguration.

[
https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Mashenkov updated IGNITE-6649:
-
Description:
For now the only way to set EvictionPolicy to IgniteConfiguration is to use
EvictionPolicy instance.
That looks error prone as user can easily share instance between caches or
cache reincarnations and got unexpected results.

E.g. it can cause an AssertionError if EvictionPolicy is reused.
Steps to reproduce.

1. Create CacheConfiguration object that will be reused.
2. Create and fill a cache.
3. Destroy cache and create cache again with same CacheConfiguration object.
4. One of next put can fails with stacktrace below.

The error is throws when EvictionPolicy tries to evict entries from cache that
has just been destroyed.
Also, EvictionPolicy object can be implicitly holds by some user objects
(together with IgniteConfiguration) that can cause memory leak.

java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71)
at
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275)
at
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250)
at
org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)

was:
For now the only way to set EvictionPolicy to IgniteConfiguration is to use
EvictionPolicy instance.
That looks error prone as user can easily share instance between caches or
cache reincarnations and got unexpected results.

E.g. it can cause an AssertionError if EvictionPolicy is reused.
Steps to reproduce.

The error is throws when EvictionPolicy tries to evict entries from cache that
has just been destroyed.

[jira] [Updated] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.


 [ 
https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6649:
-
Summary: Add EvictionPolicy factory support in IgniteConfiguration.  (was: 
Add EvitionPolicy factory support in IgniteConfiguration.)

> Add EvictionPolicy factory support in IgniteConfiguration.
> --
>
> Key: IGNITE-6649
> URL: https://issues.apache.org/jira/browse/IGNITE-6649
> Project: Ignite
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: cache
>Reporter: Andrew Mashenkov
> Fix For: 2.4
>
>
> For now the only way to set EvictionPolicy to IgniteConfiguration is to use 
> EvictionPolicy instance. 
> That looks error prone as user can easily share instance between caches or 
> cache reincarnations and got unexpected results.
> E.g. it can cause an AssertionError if EvictionPolicy is reused.
> Steps to reproduce.
> 1. Create CacheConfiguration object that will be reused.
> 2. Create and fill a cache.
> 3. Destroy cache and create cache again with same CacheConfiguration object.
> 4. One of next put can fails with stacktrace below.
> The error is throws when EvictionPolicy tries to evict entries from cache 
> that has just been destroyed.
> Also, EvictionPolicy object can be implicitly holds by some user objects 
> (together with IgniteConfiguration) that can cause memory leak.
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250)
>   at 
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6650) Introduce effective storage format for baseline topology

2017-10-17 Thread Alexey Goncharuk (JIRA)

Alexey Goncharuk created IGNITE-6650:


 Summary: Introduce effective storage format for baseline topology
 Key: IGNITE-6650
 URL: https://issues.apache.org/jira/browse/IGNITE-6650
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.3
Reporter: Alexey Goncharuk


We need to design and implement an effective baseline topology format for 
metastore so that metastore does not grow too fast.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.


[ 
https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207683#comment-16207683
 ] 

ASF GitHub Bot commented on IGNITE-5195:


Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/2862


> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Anton Vinogradov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6654) Ignite client can hang in case IgniteOOM on server

2017-10-17 Thread Mikhail Cherkasov (JIRA)

Mikhail Cherkasov created IGNITE-6654:
-

 Summary: Ignite client can hang in case IgniteOOM on server
 Key: IGNITE-6654
 URL: https://issues.apache.org/jira/browse/IGNITE-6654
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: cache, general
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov


Ignite client can hang in case IgniteOOM on server



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6653) Check equality configuration between metasore and XML


 [ 
https://issues.apache.org/jira/browse/IGNITE-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6653:
---
Description: 
To introduce another point of configuration validation between cluster (XML, 
java code) and metasore. 
Provide detailed information and decline to start cluster if different 

  was:As another point of validation need to avoid join old version nodes


> Check equality configuration between metasore and XML
> -
>
> Key: IGNITE-6653
> URL: https://issues.apache.org/jira/browse/IGNITE-6653
> Project: Ignite
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: 2.3
>Reporter: Sergey Puchnin
>  Labels: IEP-4
>
> To introduce another point of configuration validation between cluster (XML, 
> java code) and metasore. 
> Provide detailed information and decline to start cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6653) Check equality configuration between metasore and XML

Sergey Puchnin created IGNITE-6653:
--

 Summary: Check equality configuration between metasore and XML
 Key: IGNITE-6653
 URL: https://issues.apache.org/jira/browse/IGNITE-6653
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.3
Reporter: Sergey Puchnin


As another point of validation need to avoid join old version nodes



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology

2017-10-17 Thread Ilya Lantukh (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh reassigned IGNITE-5852:


Assignee: Ilya Lantukh  (was: Alexey Goncharuk)

> Cache affinity should be calculated wrt baseline topology
> -
>
> Key: IGNITE-5852
> URL: https://issues.apache.org/jira/browse/IGNITE-5852
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>  Labels: IEP-4
> Fix For: 2.4
>
>
> After we have an API for baseline topology management, we need to provide a 
> way to operate when real topology differs from the baseline. To facilitate 
> this, we need to calculate the affinity on the set of nodes which is an 
> intersection of the baseline topology and current topology



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology

2017-10-17 Thread Eduard Shangareev (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207817#comment-16207817
 ] 

Eduard Shangareev commented on IGNITE-5852:
---

Now there is the bug - if we are already active, we will call callbacks for 
activation in any case.
It causes to 2, 3 ... Checkpointers per node.

> Cache affinity should be calculated wrt baseline topology
> -
>
> Key: IGNITE-5852
> URL: https://issues.apache.org/jira/browse/IGNITE-5852
> Project: Ignite
>  Issue Type: New Feature
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>  Labels: IEP-4
> Fix For: 2.4
>
>
> After we have an API for baseline topology management, we need to provide a 
> way to operate when real topology differs from the baseline. To facilitate 
> this, we need to calculate the affinity on the set of nodes which is an 
> intersection of the baseline topology and current topology



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6655) gracefully handle AmazonS3Exception: Slow Down in TcpDiscoveryS3IpFinder

2017-10-17 Thread Konstantin Dudkov (JIRA)

Konstantin Dudkov created IGNITE-6655:
-

 Summary: gracefully handle AmazonS3Exception: Slow Down in 
TcpDiscoveryS3IpFinder
 Key: IGNITE-6655
 URL: https://issues.apache.org/jira/browse/IGNITE-6655
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.1
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov


for now if we got "AmazonS3Exception: Slow Down" in TcpDiscoveryS3IpFinder node 
stops

we should handle this situation with some kind of backoff algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT


 [ 
https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin updated IGNITE-6638:
---
Labels:   (was: IEP-4)

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6638) Add an ability for auto activate BLT


 [ 
https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin closed IGNITE-6638.
--

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6638) Add an ability for auto activate BLT


 [ 
https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin resolved IGNITE-6638.

Resolution: Duplicate

looks like a duplicate for https://issues.apache.org/jira/browse/IGNITE-5851

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6638) Add an ability for auto activate BLT


 [ 
https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Puchnin reassigned IGNITE-6638:
--

Assignee: (was: Dmitriy Pavlov)

> Add an ability for auto activate BLT
> 
>
> Key: IGNITE-6638
> URL: https://issues.apache.org/jira/browse/IGNITE-6638
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Sergey Puchnin
> Fix For: 2.4
>
>
> For further improvement BLT it'd be great to add auto activation 
> functionality. It allow to reduce stuff intervention.
> Next subtasks should be solved:
> * To change the metasrore format. Choose a format to store a node list (whole 
> node list, only id+hash, etc)
> * Add a BLT management to WebConsole
> * Add a BLT management to CLI
> * Save affinity function attributes to metastore
> * Check equality configuration between metasore and XML. Reject to start a 
> cluster if different 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.