[jira] [Updated] (IGNITE-7830) Adopt kNN regression model to the new Partitioned Dataset

2018-02-27 Thread Aleksey Zinoviev (JIRA)

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

Aleksey Zinoviev updated IGNITE-7830:
-
Summary: Adopt kNN regression model to the new Partitioned Dataset  (was: 
Adopt kNN model to the new Partitioned Dataset)

> Adopt kNN regression model to the new Partitioned Dataset
> -
>
> Key: IGNITE-7830
> URL: https://issues.apache.org/jira/browse/IGNITE-7830
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov edited comment on IGNITE-7816 at 2/28/18 7:46 AM:
--

According to Valentin Kulichenko mail scalar folder is not related to Spark 
integration.

http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-DataFrame-Examples-tp27452p27484.html


was (Author: nizhikov):
According to Valentin Kulichenk mail scalar folder is not related to Spark 
integration.

http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-DataFrame-Examples-tp27452p27484.html

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-7816:
-

According to Valentin Kulichenk mail scalar folder is not related to Spark 
integration.

http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-DataFrame-Examples-tp27452p27484.html

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

2018-02-27 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk commented on IGNITE-7717:
--

Looks good to me. [~ilantukh] can you please also check the fix?

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7572) Local cache fails to start on client node

2018-02-27 Thread Dmitry Karachentsev (JIRA)

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

Dmitry Karachentsev edited comment on IGNITE-7572 at 2/28/18 7:42 AM:
--

[~dpavlov] please review the fix. [PR 
3568|https://github.com/apache/ignite/pull/3568/commits] [TC results
|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3568%2Fhead]


was (Author: dkarachentsev):
[~dpavlov] please review the fix. [TC 
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3568%2Fhead]

> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to 
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>  
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> 

[jira] [Comment Edited] (IGNITE-7572) Local cache fails to start on client node

2018-02-27 Thread Dmitry Karachentsev (JIRA)

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

Dmitry Karachentsev edited comment on IGNITE-7572 at 2/28/18 7:42 AM:
--

[~dpavlov] please review the fix. [PR 
3568|https://github.com/apache/ignite/pull/3568/commits] [TC 
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3568%2Fhead]
 


was (Author: dkarachentsev):
[~dpavlov] please review the fix. [PR 
3568|https://github.com/apache/ignite/pull/3568/commits] [TC results
|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3568%2Fhead]

> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to 
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>  
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> 

[jira] [Commented] (IGNITE-7572) Local cache fails to start on client node

2018-02-27 Thread Dmitry Karachentsev (JIRA)

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

Dmitry Karachentsev commented on IGNITE-7572:
-

[~dpavlov] please review the fix. [TC 
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3568%2Fhead]

> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to 
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>  
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration("TEST");
> cacheConfiguration.setCacheMode(CacheMode.LOCAL);
> cfg.setCacheConfiguration(cacheConfiguration);
> cfg.setDiscoverySpi(new 

[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.

2018-02-27 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur commented on IGNITE-5357:


[~ascherbakov], please have a look at the prepared PR: 
[https://github.com/apache/ignite/pull/3578/files]

[Ci.tests of 
PR|https://ci.ignite.apache.org/viewLog.html?buildId=1113498=buildResultsDiv=IgniteTests24Java8_RunAll]
 look the same as [the master 
branch|https://ci.ignite.apache.org/viewLog.html?buildId=1113404=buildResultsDiv=IgniteTests24Java8_RunAll].

Should we add any special test cases for this change, I think it's covered by 
existing tests?

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Lukjanenko Dmitry
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7835) Scala tests appeared in wrong configurations

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-7835:
-

Ignite RDD 2_10 - 
https://ci.ignite.apache.org/viewLog.html?buildId=1114085=IgniteTests24Java8_IgniteRddSpark210=buildResultsDiv

Ignite RDD - 
https://ci.ignite.apache.org/viewLog.html?buildId=1114086=queuedBuildOverviewTab

> Scala tests appeared in wrong configurations
> 
>
> Key: IGNITE-7835
> URL: https://issues.apache.org/jira/browse/IGNITE-7835
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Scala tests are executed in wrong configurations.
> This happens because scalatest-maven-plugin doesn't properly handle 
> {{-Dtest}} settings.
> http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-Ignite-RDD-tests-tp27129p27343.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7835) Scala tests appeared in wrong configurations

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-7835:
-

TC - 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteOSGi_IgniteTests24Java8=pull%2F3570%2Fhead=buildTypeStatusDiv

> Scala tests appeared in wrong configurations
> 
>
> Key: IGNITE-7835
> URL: https://issues.apache.org/jira/browse/IGNITE-7835
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Scala tests are executed in wrong configurations.
> This happens because scalatest-maven-plugin doesn't properly handle 
> {{-Dtest}} settings.
> http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-Ignite-RDD-tests-tp27129p27343.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-7836) ExchangeFuture misses onBaselineTopologyChanged callback when forceReassignment is false

2018-02-27 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk resolved IGNITE-7836.
--
Resolution: Fixed

Merged to master

> ExchangeFuture misses onBaselineTopologyChanged callback when 
> forceReassignment is false
> 
>
> Key: IGNITE-7836
> URL: https://issues.apache.org/jira/browse/IGNITE-7836
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6868:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-6868 Concurrency performance fix



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

$ git pull https://github.com/alex-plekhanov/ignite 
ignite-6868-concurrency-fix

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

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


commit 97a606506b877c405f503a78778a2be1d1ead3c9
Author: Aleksey Plekhanov 
Date:   2018-02-28T07:06:46Z

IGNITE-6868 Concurrency performance fix




> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7836) ExchangeFuture misses onBaselineTopologyChanged callback when forceReassignment is false

2018-02-27 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk reassigned IGNITE-7836:


Assignee: Alexey Goncharuk

> ExchangeFuture misses onBaselineTopologyChanged callback when 
> forceReassignment is false
> 
>
> Key: IGNITE-7836
> URL: https://issues.apache.org/jira/browse/IGNITE-7836
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7836) ExchangeFuture misses onBaselineTopologyChanged callback when forceReassignment is false

2018-02-27 Thread Alexey Goncharuk (JIRA)
Alexey Goncharuk created IGNITE-7836:


 Summary: ExchangeFuture misses onBaselineTopologyChanged callback 
when forceReassignment is false
 Key: IGNITE-7836
 URL: https://issues.apache.org/jira/browse/IGNITE-7836
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Alexey Goncharuk
 Fix For: 2.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7835) Scala tests appeared in wrong configurations

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-7835:
-

https://github.com/apache/ignite/pull/3570/files

> Scala tests appeared in wrong configurations
> 
>
> Key: IGNITE-7835
> URL: https://issues.apache.org/jira/browse/IGNITE-7835
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Scala tests are executed in wrong configurations.
> This happens because scalatest-maven-plugin doesn't properly handle 
> {{-Dtest}} settings.
> http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-Ignite-RDD-tests-tp27129p27343.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7835) Scala tests appeared in wrong configurations

2018-02-27 Thread Nikolay Izhikov (JIRA)
Nikolay Izhikov created IGNITE-7835:
---

 Summary: Scala tests appeared in wrong configurations
 Key: IGNITE-7835
 URL: https://issues.apache.org/jira/browse/IGNITE-7835
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.5


Scala tests are executed in wrong configurations.

This happens because scalatest-maven-plugin doesn't properly handle {{-Dtest}} 
settings.

http://apache-ignite-developers.2346864.n4.nabble.com/TeamCity-Ignite-RDD-tests-tp27129p27343.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7821) Unify and improve Apache Ignite and Web Console Dockerfiles

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov updated IGNITE-7821:
-
Description: 
# Unify approach to docker build -- add instructions about how to build 
specific docker images from binaries .
# Change Apache Ignite's Dockerfile to get binaries from local build.

  was:
# Update Dockerfiles in order to match upcoming 2.4 release.
# Change Apache Ignite's Dockerfile to get binaries from local build.


> Unify and improve Apache Ignite and Web Console Dockerfiles
> ---
>
> Key: IGNITE-7821
> URL: https://issues.apache.org/jira/browse/IGNITE-7821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Unify approach to docker build -- add instructions about how to build 
> specific docker images from binaries .
> # Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7821) Unify and improve Apache Ignite and Web Console Dockerfiles

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov updated IGNITE-7821:
-
Fix Version/s: (was: 2.4)
   2.5

> Unify and improve Apache Ignite and Web Console Dockerfiles
> ---
>
> Key: IGNITE-7821
> URL: https://issues.apache.org/jira/browse/IGNITE-7821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Update Dockerfiles in order to match upcoming 2.4 release.
> # Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7821) Unify and improve Apache Ignite and Web Console Dockerfiles

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov updated IGNITE-7821:
-
Summary: Unify and improve Apache Ignite and Web Console Dockerfiles  (was: 
Update Apache Ignite and Web Console Dockerfile for 2.4 version and local build)

> Unify and improve Apache Ignite and Web Console Dockerfiles
> ---
>
> Key: IGNITE-7821
> URL: https://issues.apache.org/jira/browse/IGNITE-7821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # Update Dockerfiles in order to match upcoming 2.4 release.
> # Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7706) Data streamer hangs due to uploading instances of updated class

2018-02-27 Thread Roman Guseinov (JIRA)

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

Roman Guseinov reassigned IGNITE-7706:
--

Assignee: Roman Guseinov

> Data streamer hangs due to uploading instances of updated class
> ---
>
> Key: IGNITE-7706
> URL: https://issues.apache.org/jira/browse/IGNITE-7706
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: streamer-hangs-issue.zip
>
>
> Use case:
> 1. Cache is located only at specific nodes GROUP-1.
> 2. Other nodes GROUP-2 is used for other caches.
> 3. Also, there are nodes for streaming GROUP-3. Cache configuration contains 
> Person class as value type of QueryEntity.
> If we restart GROUP-1 (not all cluster) and restart GROUP-3 with updated 
> configuration and Person class (changed a field type) then streamer hangs 
> (without any messages).
> Reproducer (with README.md) in the attached file (streamer-hangs-issue.zip).
> It seems the problem in handling "Binary type has different field types" 
> exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

2018-02-27 Thread Denis Magda (JIRA)

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

Denis Magda edited comment on IGNITE-7655 at 2/28/18 4:31 AM:
--

[~NIzhikov] , thanks a lot for that!

[~abchaudhri] , please do a primarily review and editing making sure the doc is 
perceived as a getting started guide. Once you're done assign this task to me, 
I'll check it up as an Ignite user who has never used this new feature before 
and willing to start.


was (Author: dmagda):
[~NIzhikov] , thanks a lot for that!

[~abchaudhri] , please do a primarily review and editing making sure the doc is 
perceived as a getting started guide. Once you're done assign this task to me, 
I'll check it up as an Ignite user who have never used this new feature before 
and willing to start.

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Akmal Chaudhri
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

2018-02-27 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-7655:
-

[~NIzhikov] , thanks a lot for that!

[~abchaudhri] , please do a primarily review and editing making sure the doc is 
perceived as a getting started guide. Once you're done assign this task to me, 
I'll check it up as an Ignite user who have never used this new feature before 
and willing to start.

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Akmal Chaudhri
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-7816:
-

[~NIzhikov] , looks good to me but I'm not sure the community will allow 
merging the changes into 2.4. Please bring up this question on @dev.

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7825) ODBC: Update specification documentation

2018-02-27 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-7825:
-

[~isapego] , could you please specify what was changed (paragraphs, new 
section, sentences, etc.)? The doc is huge and it's not effective to read from 
the beginning all the time.

Feel free to ask [~pgarg] to review the changes right away.

 

 

> ODBC: Update specification documentation
> 
>
> Key: IGNITE-7825
> URL: https://issues.apache.org/jira/browse/IGNITE-7825
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: documentation, odbc
> Fix For: 2.4
>
>
> Need to update the following doc 
> [https://apacheignite-sql.readme.io/v2.3/docs/specification] according to the 
> newly implemented features in 2.4.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-5357:


GitHub user DALukjanenko opened a pull request:

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

IGNITE-5357 replicated cache reads load balancing was added



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

$ git pull https://github.com/DALukjanenko/ignite IGNITE-5357.master

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

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


commit 5cc0906838f4916060149a62b51d6904f63a11a7
Author: Dmitry Lukjanenko 
Date:   2018-02-28T00:14:36Z

IGNITE-5357 replicated cache reads load balancing was added




> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Lukjanenko Dmitry
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7651) Assertion error on cache start while reading meta pages

2018-02-27 Thread Eduard Shangareev (JIRA)

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

Eduard Shangareev updated IGNITE-7651:
--
Fix Version/s: 2.5

> Assertion error on cache start while reading meta pages
> ---
>
> Key: IGNITE-7651
> URL: https://issues.apache.org/jira/browse/IGNITE-7651
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Critical
> Fix For: 2.5
>
>
> We recently have added assertion. Now it has found issue with start cache 
> after restart.
> {code:java}
> java.lang.AssertionError: calculatedOffset=16384, allocated=8192, 
> headerSize=4096
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:341)
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:322)
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:306)
> at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:658)
> at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:578)
> at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:130)
> at 
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:167)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.reuse.ReuseListImpl.(ReuseListImpl.java:56)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.initDataStructures(GridCacheOffheapManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.start(IgniteCacheOffheapManagerImpl.java:131)
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.start(CacheGroupContext.java:893)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1979)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:769)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-6868:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-6868 Concurrency performance fix



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-6868-perf-fix

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

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


commit b3544e263b9c22917fdf039441102668e5627cad
Author: Aleksey Plekhanov 
Date:   2018-02-27T15:35:43Z

IGNITE-6868 Concurrency performance fix

commit 515b478d493a42d3c871a65057878da0f0dfbfb8
Author: Aleksey Plekhanov 
Date:   2018-02-27T22:06:12Z

IGNITE-6868 WIP

commit d6127866d8e300a6de22fe37be5d7ba725790427
Author: Aleksey Plekhanov 
Date:   2018-02-27T22:13:56Z

IGNITE-6868 Concurrency performance fix




> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7816:


Github user nizhikov closed the pull request at:

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


> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing

2018-02-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov edited comment on IGNITE-6083 at 2/27/18 5:27 PM:
---

[~agoncharuk] Hi!

In current master branch I came across odd behavior, consider the following 
scenario:

T1:
Start optimistic READ_COMMITTED tx, run cache.invoke(); // This cache invoke 
fetches the key from primary node and stores into tx entry. This Invoke doesn't 
change the value.
T2:
run cache.put();// which overwrites the original value;
T1:
run cache.read();// Here and futher old value will be returned, because of 
invoke() called above.
commit();

In this scenario we have no Non-Repeatable Reads, which seems incorrect for 
READ_COMMITTED isolation mode. 
Do you agree ? If yes, I will file another new ticket, fixing it.

Also, I run the test in PESSIMISTIC mode, it fails. Need more fixes


was (Author: alexey kuznetsov):
[~agoncharuk] Hi!

In current master branch I came across odd behavior, consider the following 
scenario:

T1:
Start optimistic READ_COMMITTED tx, run cache.invoke(); // This cache invoke 
fetches the key from primary node and stores into tx entry. This Invoke doesn't 
change the value.
T2:
run cache.put();// which overwrites the original value;
T1:
run cache.read();// Here and futher old value will be returned, because of 
invoke() called above.
commit();

In this scenario we have no Non-Repeatable Reads, which seems incorrect for 
READ_COMMITTED isolation mode. 
Do you agree ? If yes, I will file another new ticket, fixing it.

> Null value have appear in the entry processor, but the entry is existing
> 
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute 
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}} 
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at 
> second.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-5975) [Test Failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov commented on IGNITE-5975:


GridCacheReplicatedDataStructuresFailoverSelfTest is also failed. This test was 
cause of constant suite timeouts, muted in master

> [Test Failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure
> ---
>
> Key: IGNITE-5975
> URL: https://issues.apache.org/jira/browse/IGNITE-5975
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=758964=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId-2988875689386264427.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-5975) [Test Failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov updated IGNITE-5975:
---
Labels: MakeTeamcityGreenAgain Muted_test  (was: MakeTeamcityGreenAgain)

> [Test Failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreSingleNodeFailure
> ---
>
> Key: IGNITE-5975
> URL: https://issues.apache.org/jira/browse/IGNITE-5975
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=758964=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId-2988875689386264427.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

2018-02-27 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-7834:
--

 Summary: Ignite Queries 2 fail rate is more than 95%: 
DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
 Key: IGNITE-7834
 URL: https://issues.apache.org/jira/browse/IGNITE-7834
 Project: Ignite
  Issue Type: Test
  Components: sql
Reporter: Dmitriy Pavlov


Queries 2 suite has unstable tests DynamicColumns...
Initially contrubuted by [~al.psc] in [IGNITE-5572]

https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv

Last 10 runs statistics:
{noformat}
Ignite Queries 2 [ tests 16 ]
 [2] IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
 (fail rate 5,8%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
 (fail rate 5,8%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
 (fail rate 5,8%) 
 [2] IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
 (fail rate 3,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
 (fail rate 3,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
 (fail rate 3,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
 (fail rate 3,6%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
 (fail rate 2,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy 
(fail rate 2,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
 (fail rate 2,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
 (fail rate 2,5%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove (fail 
rate 2,2%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
 (fail rate 1,9%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
 (fail rate 1,8%) 
 IgniteBinaryCacheQueryTestSuite2: 
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
 (fail rate 1,0%) 
IgniteBinaryCacheQueryTestSuite2: 
DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect (fail 
rate 0,4%) 
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7467:


GitHub user Jokser opened a pull request:

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

IGNITE-7467 Partition counters validation



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

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

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

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


commit d52d7a5395b86c3f35ba793751e3f0aa2cb35b8a
Author: Pavel Kovalenko 
Date:   2018-01-19T15:53:02Z

IGNITE-7467 WIP

commit cbb4a26f99bc006fe459799b84d01a9001a6ac4e
Author: Pavel Kovalenko 
Date:   2018-02-27T16:22:13Z

IGNITE-7467 Validate partition update counters and cache sizes.

commit 92588393b29f57ac27666b48efe859ae7ebb752b
Author: Pavel Kovalenko 
Date:   2018-02-27T16:22:19Z

Merge branch 'master' into ignite-7467

commit d9739847e2420a2ddfea00a42f03b261fe16c6f7
Author: Pavel Kovalenko 
Date:   2018-02-27T16:23:57Z

IGNITE-7467 Cleaned up test.

commit 1029c84cfec3bbb8922cbcda408d0703477aed82
Author: Pavel Kovalenko 
Date:   2018-02-27T16:28:22Z

IGNITE-7467 Missed java docs.




> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
>
> In Ignite we heavily rely on an invariant that under no load owning 
> partitions will have equal sizes and, more importantly, equal partition 
> counters. This invariant becomes even more important when persistence is 
> enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7833) Find out possible ways to handle partition update counters inconsistency

2018-02-27 Thread Pavel Kovalenko (JIRA)
Pavel Kovalenko created IGNITE-7833:
---

 Summary: Find out possible ways to handle partition update 
counters inconsistency
 Key: IGNITE-7833
 URL: https://issues.apache.org/jira/browse/IGNITE-7833
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Pavel Kovalenko


We should think about possible ways to resolve the situation when we observe 
that partition update counters for the same partitions (primary-backup) are 
different on some nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7832) Partition lost events looks broken.

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov edited comment on IGNITE-7832 at 2/27/18 4:15 PM:
-

Is it duplicate to https://issues.apache.org/jira/browse/IGNITE-5078 ? Or it is 
more general issue?


was (Author: dpavlov):
Is it duplicate to https://issues.apache.org/jira/browse/IGNITE-5078 ? Or it is 
more general issues?

> Partition lost events looks broken.
> ---
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only, however, some of lost 
> partitions should be owned by 3-rd node regarding a new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7832) Partition lost events looks broken.

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov commented on IGNITE-7832:


Is it duplicate to https://issues.apache.org/jira/browse/IGNITE-5078 ? Or it is 
more general issues?

> Partition lost events looks broken.
> ---
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only, however, some of lost 
> partitions should be owned by 3-rd node regarding a new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7531) SQL: Create data load benchmarks

2018-02-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-7531:
--

[~pkouznet], the patch looks good. My comments:
1. Access modifiers. Why publics or package private:
1.1. {{AbstractUploadBenchmark#INSERT_ROWS_CNT}} - not constant, don't use 
upper case. 
1.2. {{AbstractUploadBenchmark#queries}} 
1.3.  {{BatchedInsertBenchmark#BATCH_SIZE}}
2. {{QueryFactory}} members. Why {{dropTableIfExists, count, deleteAll, 
turnOn/OffWal} are not public constant. OK may be private constant for unify 
with {{create/insert/copy}} methods


> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7832) Partition lost events looks broken.

2018-02-27 Thread Andrew Mashenkov (JIRA)

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

Andrew Mashenkov updated IGNITE-7832:
-
Description: 
Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
 PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node.
 I observe partition lost events on 2-nd node only, however, some of lost 
partitions should be owned by 3-rd node regarding a new topology. 
 Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node.
 No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
 Cache.lostPartitions() returns empty resultset.

Looks like partition lost events mechanics is broken and should be fixed.

  was:
Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
 PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node.
 I observe partition lost events on 2-nd node only however, some of them should 
be owned by 3-rd node according new topology. 
 Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node.
 No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
 Cache.lostPartitions() returns empty resultset.

Looks like partition lost events mechanics is broken and should be fixed.


> Partition lost events looks broken.
> ---
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only, however, some of lost 
> partitions should be owned by 3-rd node regarding a new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7832) Partition lost events looks broken.

2018-02-27 Thread Andrew Mashenkov (JIRA)

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

Andrew Mashenkov updated IGNITE-7832:
-
Description: 
Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
 PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node.
 I observe partition lost events on 2-nd node only however, some of them should 
be owned by 3-rd node according new topology. 
 Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node.
 No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
 Cache.lostPartitions() returns empty resultset.

Looks like partition lost events mechanics is broken and should be fixed.

  was:
Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node. 
I observer partition lost events on 2-nd node only however, some of them should 
be owned by 3-rd node according new topology. 
Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node. 
No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
Cache.lostPartitions() returns empty resultset.



Looks like partition lost events mechanics is broken and should be fixed.


> Partition lost events looks broken.
> ---
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only however, some of them 
> should be owned by 3-rd node according new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7832) Partition lost events looks broken.

2018-02-27 Thread Andrew Mashenkov (JIRA)
Andrew Mashenkov created IGNITE-7832:


 Summary: Partition lost events looks broken.
 Key: IGNITE-7832
 URL: https://issues.apache.org/jira/browse/IGNITE-7832
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Andrew Mashenkov
 Fix For: 2.5


Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node. 
I observer partition lost events on 2-nd node only however, some of them should 
be owned by 3-rd node according new topology. 
Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node. 
No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
Cache.lostPartitions() returns empty resultset.



Looks like partition lost events mechanics is broken and should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-02-27 Thread Ilya Lantukh (JIRA)

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

Ilya Lantukh updated IGNITE-7831:
-
Comment: was deleted

(was: Assertions are used to indicate problems in internal logic, while 
persistence might also get corrupted by various external reasons. It also makes 
uniform handling of such issues considerably harder, because most places of 
code in Ignite ignore Errors.)

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Priority: Major
>  Labels: iep-14
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-02-27 Thread Ilya Lantukh (JIRA)

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

Ilya Lantukh updated IGNITE-7831:
-
Description: Assertions are used to indicate problems in internal logic, 
while persistence might also get corrupted by various external reasons. It also 
makes uniform handling of such issues considerably harder, because most places 
of code in Ignite ignore Errors.

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Priority: Major
>  Labels: iep-14
>
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because most places of code in 
> Ignite ignore Errors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-02-27 Thread Ilya Lantukh (JIRA)

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

Ilya Lantukh commented on IGNITE-7831:
--

Assertions are used to indicate problems in internal logic, while persistence 
might also get corrupted by various external reasons. It also makes uniform 
handling of such issues considerably harder, because most places of code in 
Ignite ignore Errors.

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Priority: Major
>  Labels: iep-14
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7811) ODBC: Implement connection failover

2018-02-27 Thread Igor Sapego (JIRA)

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

Igor Sapego updated IGNITE-7811:

Labels: odbc  (was: )

> ODBC: Implement connection failover
> ---
>
> Key: IGNITE-7811
> URL: https://issues.apache.org/jira/browse/IGNITE-7811
> Project: Ignite
>  Issue Type: New Feature
>  Components: odbc
>Affects Versions: 2.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: odbc
> Fix For: 2.5
>
>
> Currently user has to manually connect to some specific Ignite server.
> Implement some kind of automatic failover where ODBC driver knows about 
> multiple nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-02-27 Thread Ilya Lantukh (JIRA)
Ilya Lantukh created IGNITE-7831:


 Summary: Throw Exceptions instead of AssertionErrors when reading 
from corrupted persistence
 Key: IGNITE-7831
 URL: https://issues.apache.org/jira/browse/IGNITE-7831
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Lantukh






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing

2018-02-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov commented on IGNITE-6083:
--

[~agoncharuk] Hi!

In current master branch I came across odd behavior, consider the following 
scenario:

T1:
Start optimistic READ_COMMITTED tx, run cache.invoke(); // This cache invoke 
fetches the key from primary node and stores into tx entry. This Invoke doesn't 
change the value.
T2:
run cache.put();// which overwrites the original value;
T1:
run cache.read();// Here and futher old value will be returned, because of 
invoke() called above.
commit();

In this scenario we have no Non-Repeatable Reads, which seems incorrect for 
READ_COMMITTED isolation mode. 
Do you agree ? If yes, I will file another new ticket, fixing it.

> Null value have appear in the entry processor, but the entry is existing
> 
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute 
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}} 
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at 
> second.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7830) Adopt kNN model to the new Partitioned Dataset

2018-02-27 Thread Aleksey Zinoviev (JIRA)
Aleksey Zinoviev created IGNITE-7830:


 Summary: Adopt kNN model to the new Partitioned Dataset
 Key: IGNITE-7830
 URL: https://issues.apache.org/jira/browse/IGNITE-7830
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7829) Adopt kNN regression example to the new Partitioned Dataset

2018-02-27 Thread Aleksey Zinoviev (JIRA)
Aleksey Zinoviev created IGNITE-7829:


 Summary: Adopt kNN regression example to the new Partitioned 
Dataset
 Key: IGNITE-7829
 URL: https://issues.apache.org/jira/browse/IGNITE-7829
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm

2018-02-27 Thread Aleksey Zinoviev (JIRA)
Aleksey Zinoviev created IGNITE-7828:


 Summary: Adopt yardstick tests for the new version of kNN 
regression algorithm
 Key: IGNITE-7828
 URL: https://issues.apache.org/jira/browse/IGNITE-7828
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7827) Adopt kNN regression to the new Partitioned Dataset

2018-02-27 Thread Aleksey Zinoviev (JIRA)
Aleksey Zinoviev created IGNITE-7827:


 Summary: Adopt kNN regression to the new Partitioned Dataset
 Key: IGNITE-7827
 URL: https://issues.apache.org/jira/browse/IGNITE-7827
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (IGNITE-7785) SQL query with COUNT and UNION in sub-query produces JdbcSQLException

2018-02-27 Thread Pavel Vinokurov (JIRA)

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

Pavel Vinokurov updated IGNITE-7785:

Comment: was deleted

(was: Another one reproducer with GROUP BY:

CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary 
DECIMAL);
CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR);
CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, 
market_value DECIMAL);

INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), 
(3, 3, 300);
INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3');
INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 1), 
(2, 2, 2), (3, 3, 3); CREATE TABLE Address (id INTEGER PRIMARY KEY, 
person_id INTEGER, city VARCHAR);INSERT INTO Person (id, company_id, salary) 
VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300);INSERT INTO Address (id, 
person_id, city) VALUES (1, 1, 'san francisco'), (2, 2, 'paris'), (3, 3, 'new 
york');INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 
'n3');INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 
1), (2, 2, 2), (3, 3, 3);

 

SELECT a.idFROM  (SELECT     p1.id as pid,     p1.salary,     p1.company_id   
FROM Person p1   WHERE p1.id = 1   UNION   SELECT     p2.id as pid,     
p2.salary,     p2.company_id   FROM Person p2   WHERE p2.id = 2)  p  LEFT JOIN 
Company c ON p.company_id = c.id  LEFT JOIN Company_Value cv ON c.id = 
cv.company_id  LEFT JOIN Address a ON a.person_id = p.pid;

 

Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not found; SQL 
statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3  LEFT OUTER JOIN 
PUBLIC.COMPANY_VALUE CV__Z4  ON C__Z3.ID = CV__Z4.COMPANY_ID  LEFT OUTER JOIN 
PUBLIC.ADDRESS A__Z5  ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 [42122-195]

 

 

 

 )

> SQL query with COUNT and UNION in sub-query produces JdbcSQLException
> -
>
> Key: IGNITE-7785
> URL: https://issues.apache.org/jira/browse/IGNITE-7785
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
>  CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
>  INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
>  INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL Query:
> SELECT count(1) FROM person p
>  LEFT JOIN (select id from company union select id from company) as c on 
> c.id=p.company_id
> JDBC Exception:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
> the GROUP BY list; SQL statement:
> SELECT
> P__Z0.COMPANY_ID __C0_0,
> COUNT(1) __C0_1
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7796) Adopt kNN classification example to the new datasets

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7796:


GitHub user zaleslaw opened a pull request:

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

IGNITE-7796: Adopt kNN classification example to the new datasets



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

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

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

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


commit ae9741f36d360c2deada2804baa2cec1fb0254ea
Author: zaleslaw 
Date:   2018-02-14T14:42:16Z

Added draft sample

commit 531b336d569456fdee11a424878bd119b3b63c28
Author: Zinoviev Alexey 
Date:   2018-02-22T11:42:05Z

IGNITE-7702: Added tests

commit ad71203ca565f9ef688bea1924bc77052818e236
Author: Zinoviev Alexey 
Date:   2018-02-22T17:06:51Z

IGNITE-7702: Fixed bug

commit fd8f976f3d42066139b0359709fb8ea6eded2f0f
Author: Zinoviev Alexey 
Date:   2018-02-22T17:09:32Z

IGNITE-7702: remove incorrect examples

commit 4622dc6df0bf48c800dc413a24278d227e96f6aa
Author: Zinoviev Alexey 
Date:   2018-02-22T17:10:17Z

IGNITE-7702: Rewrite KNN classifications

commit 3a661d9e0627b8696c580d4f3587f51b30800166
Author: Zinoviev Alexey 
Date:   2018-02-22T17:11:28Z

IGNITE-7702: Delete incorrect benchmarks

commit c0e2edfbd3893ad693a72462315f4b7c5bd61ac6
Author: Zinoviev Alexey 
Date:   2018-02-22T17:36:15Z

IGNITE-7702: Fixed tests

commit cee126f3a2eedbe88166111d11aa6d985444b924
Author: Zinoviev Alexey 
Date:   2018-02-27T13:41:37Z

IGNITE-7702: Fixed licenses

commit a7b8e8ad773e422ff43d484fa62e8ef58553a802
Author: Zinoviev Alexey 
Date:   2018-02-27T13:48:45Z

Merge branch 'master' into ignite-7702

commit c63ab415bad489efc93e43538d866fcc5780b642
Author: Zinoviev Alexey 
Date:   2018-02-27T13:49:25Z

IGNITE-7702: Fixed merged conflicts

commit c06a7a00f735e71d659cd6794a6817f9a9fba0e2
Author: Zinoviev Alexey 
Date:   2018-02-27T14:02:55Z

IGNITE-7796: Added example




> Adopt kNN classification example to the new datasets
> 
>
> Key: IGNITE-7796
> URL: https://issues.apache.org/jira/browse/IGNITE-7796
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7583) SQL TX: Change secondary indexes structure

2018-02-27 Thread Roman Kondakov (JIRA)

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

Roman Kondakov edited comment on IGNITE-7583 at 2/27/18 2:00 PM:
-

Page layouts after this patch. Changes are highlighted with a bold font.

Data page entry layout (DataPageIO):
 # Payload: 2 bytes. Payload size. Highest bit == fragmented flag.
 # Next link: 8 or 0 bytes. Link to the next page if fragmented flag == true, 
or empty if row is not fragmented
 # *MVCC info: 32 or 0 bytes. Create TX number - xid_min (16 bytes - two longs: 
coordinator id and counter id) and delete TX number - xid_max (16 bytes - two 
longs: coordinator id and counter id) if MVCC is enabled, or 0 bytes if MVCC is 
not enabled. These MVCC info is always located on the very first data page in 
pages chain for fast access to these fields.*
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # Key: >5 bytes. 4 bytes - key length, 1 byte - key type and others - is a 
byte array with the key binary representation.
 # Expire time: 8 bytes.
 # Value: >5 bytes. 4 bytes - value length, 1 byte - value type and others - is 
a byte array with the value binary representation.
 # Grid cache version: 17 or 33 bytes - depends on GridCacheVersion 
implementation.

Cache data tree item layout (AbstractDataInnerIO/AbstractDataLeafIO):
 # Link: 8 bytes. Link to row.
 # Hash: 4 bytes. Row key hash.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # *MVCC info: 16 or 0 bytes. 0 if MVCC is disabled. If enabled it stores 
create TX number - xid_min (16 bytes - two longs: coordinator id and counter 
id).*

Index tree item layout (AbstractH2...IO):
 # Link: 8 bytes. Link to row.
 # *MVCC info: 16 or 0 bytes. 0 if MVCC is disabled. If enabled it stores 
create TX number - xid_min (16 bytes - two longs: coordinator id and counter 
id).*
 # Payload.


was (Author: rkondakov):
Page layouts after this patch.

Data page entry layout (DataPageIO):
 # Payload: 2 bytes. Payload size. Highest bit == fragmented flag.
 # Next link: 8 or 0 bytes. Link to the next page if fragmented flag == true, 
or empty if row is not fragmented
 # MVCC info: 32 or 0 bytes. Create TX number - xid_min (16 bytes - two longs: 
coordinator id and counter id) and delete TX number - xid_max (16 bytes - two 
longs: coordinator id and counter id) if MVCC is enabled, or 0 bytes if MVCC is 
not enabled. These MVCC info is always located on the very first data page in 
pages chain for fast access to these fields.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # Key: >5 bytes. 4 bytes - key length, 1 byte - key type and others - is a 
byte array with the key binary representation.
 # Expire time: 8 bytes.
 # Value: >5 bytes. 4 bytes - value length, 1 byte - value type and others - is 
a byte array with the value binary representation.
 # Grid cache version: 17 or 33 bytes - depends on GridCacheVersion 
implementation.

Cache data tree item layout (AbstractDataInnerIO/AbstractDataLeafIO):
 # Link: 8 bytes. Link to row.
 # Hash: 4 bytes. Row key hash.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).

Index tree item layout (AbstractH2...IO):
 # Link: 8 bytes. Link to row.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).
 # Payload.

> SQL TX: Change secondary indexes structure
> --
>
> Key: IGNITE-7583
> URL: https://issues.apache.org/jira/browse/IGNITE-7583
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
>
> We need to change:
>  * rows with the same key and different versions should be placed in a tree 
> ordered by version decending
>  * move next version from BTree leafs to data rows
>  * filters according to next logic: the row is visible if leaf version is 
> less than assigned and not active and max_version of referenced row is NA or 
> heigher than assigned or active 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-7583) SQL TX: Change secondary indexes structure

2018-02-27 Thread Roman Kondakov (JIRA)

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

Roman Kondakov edited comment on IGNITE-7583 at 2/27/18 1:58 PM:
-

Page layouts after this patch.

Data page entry layout (DataPageIO):
 # Payload: 2 bytes. Payload size. Highest bit == fragmented flag.
 # Next link: 8 or 0 bytes. Link to the next page if fragmented flag == true, 
or empty if row is not fragmented
 # MVCC info: 32 or 0 bytes. Create TX number - xid_min (16 bytes - two longs: 
coordinator id and counter id) and delete TX number - xid_max (16 bytes - two 
longs: coordinator id and counter id) if MVCC is enabled, or 0 bytes if MVCC is 
not enabled. These MVCC info is always located on the very first data page in 
pages chain for fast access to these fields.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # Key: >5 bytes. 4 bytes - key length, 1 byte - key type and others - is a 
byte array with the key binary representation.
 # Expire time: 8 bytes.
 # Value: >5 bytes. 4 bytes - value length, 1 byte - value type and others - is 
a byte array with the value binary representation.
 # Grid cache version: 17 or 33 bytes - depends on GridCacheVersion 
implementation.

Cache data tree item layout (AbstractDataInnerIO/AbstractDataLeafIO):
 # Link: 8 bytes. Link to row.
 # Hash: 4 bytes. Row key hash.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).

Index tree item layout (AbstractH2...IO):
 # Link: 8 bytes. Link to row.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).
 # Payload.


was (Author: rkondakov):
Data page entry layout (DataPageIO):
 # Payload: 2 bytes. Payload size. Highest bit == fragmented flag.
 # Next link: 8 or 0 bytes. Link to the next page if fragmented flag == true, 
or empty if row is not fragmented
 # MVCC info: 32 or 0 bytes. Create TX number - xid_min (16 bytes - two longs: 
coordinator id and counter id) and delete TX number - xid_max (16 bytes - two 
longs: coordinator id and counter id) if MVCC is enabled, or 0 bytes if MVCC is 
not enabled. These MVCC info is always located on the very first data page in 
pages chain for fast access to these fields.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # Key: >5 bytes. 4 bytes - key length, 1 byte - key type and others - is a 
byte array with the key binary representation.
 # Expire time: 8 bytes.
 # Value: >5 bytes. 4 bytes - value length, 1 byte - value type and others - is 
a byte array with the value binary representation.
 # Grid cache version: 17 or 33 bytes - depends on GridCacheVersion 
implementation.

Cache data tree item layout (AbstractDataInnerIO/AbstractDataLeafIO):
 # Link: 8 bytes. Link to row.
 # Hash: 4 bytes. Row key hash.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).

Index tree item layout (AbstractH2...IO):
 # Link: 8 bytes. Link to row.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).
 # Payload.

> SQL TX: Change secondary indexes structure
> --
>
> Key: IGNITE-7583
> URL: https://issues.apache.org/jira/browse/IGNITE-7583
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
>
> We need to change:
>  * rows with the same key and different versions should be placed in a tree 
> ordered by version decending
>  * move next version from BTree leafs to data rows
>  * filters according to next logic: the row is visible if leaf version is 
> less than assigned and not active and max_version of referenced row is NA or 
> heigher than assigned or active 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7583) SQL TX: Change secondary indexes structure

2018-02-27 Thread Roman Kondakov (JIRA)

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

Roman Kondakov commented on IGNITE-7583:


Data page entry layout (DataPageIO):
 # Payload: 2 bytes. Payload size. Highest bit == fragmented flag.
 # Next link: 8 or 0 bytes. Link to the next page if fragmented flag == true, 
or empty if row is not fragmented
 # MVCC info: 32 or 0 bytes. Create TX number - xid_min (16 bytes - two longs: 
coordinator id and counter id) and delete TX number - xid_max (16 bytes - two 
longs: coordinator id and counter id) if MVCC is enabled, or 0 bytes if MVCC is 
not enabled. These MVCC info is always located on the very first data page in 
pages chain for fast access to these fields.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # Key: >5 bytes. 4 bytes - key length, 1 byte - key type and others - is a 
byte array with the key binary representation.
 # Expire time: 8 bytes.
 # Value: >5 bytes. 4 bytes - value length, 1 byte - value type and others - is 
a byte array with the value binary representation.
 # Grid cache version: 17 or 33 bytes - depends on GridCacheVersion 
implementation.

Cache data tree item layout (AbstractDataInnerIO/AbstractDataLeafIO):
 # Link: 8 bytes. Link to row.
 # Hash: 4 bytes. Row key hash.
 # Cache id: 4 or 0 bytes. Cache ID if it is a cache in a cache group.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).

Index tree item layout (AbstractH2...IO):
 # Link: 8 bytes. Link to row.
 # MVCC info: 16 or 0 bytes. 0 if MVCC os disabled. If enabled it stores create 
TX number - xid_min (16 bytes - two longs: coordinator id and counter id).
 # Payload.

> SQL TX: Change secondary indexes structure
> --
>
> Key: IGNITE-7583
> URL: https://issues.apache.org/jira/browse/IGNITE-7583
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
>
> We need to change:
>  * rows with the same key and different versions should be placed in a tree 
> ordered by version decending
>  * move next version from BTree leafs to data rows
>  * filters according to next logic: the row is visible if leaf version is 
> less than assigned and not active and max_version of referenced row is NA or 
> heigher than assigned or active 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7826) DStatProbe benchmark empty result output

2018-02-27 Thread Burov Ilya (JIRA)
Burov Ilya created IGNITE-7826:
--

 Summary: DStatProbe benchmark empty result output
 Key: IGNITE-7826
 URL: https://issues.apache.org/jira/browse/IGNITE-7826
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.3
 Environment: Ubuntu 17.10

apache-ignite-fabric-2.3.0-bin

Dstat 0.7.3
Platform posix/linux2
Kernel 4.13.0-36-generic
Python 2.7.14 (default, Sep 23 2017, 22:06:14) 
[GCC 7.2.0]

Terminal type: xterm-256color (color support)
Reporter: Burov Ilya
 Attachments: DStatProbe.csv, dstat.log

DStatProbe creates empty result csv report due to dstat command output parsing 
error.

Sample csv file and part of driver log included.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7825) ODBC: Update specification documentation

2018-02-27 Thread Igor Sapego (JIRA)
Igor Sapego created IGNITE-7825:
---

 Summary: ODBC: Update specification documentation
 Key: IGNITE-7825
 URL: https://issues.apache.org/jira/browse/IGNITE-7825
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.3
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.4


Need to update the following doc 
[https://apacheignite-sql.readme.io/v2.3/docs/specification] according to the 
newly implemented features in 2.4.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7785) SQL query with COUNT and UNION in sub-query produces JdbcSQLException

2018-02-27 Thread Alexander Paschenko (JIRA)

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

Alexander Paschenko commented on IGNITE-7785:
-

[~pvinokurov],

Initial query is a bit weird as long as it has union of a table with itself.

In absence of {{UNION ALL}} clause, that subquery

{{(select id from company union all select id from company)}}

should give same result as single {{SELECT id FROM Company}}, and thus in 
initial case that UNION is redundant - if you remove UNION, query works.

However, if you add ALL to UNION, query works - however, in this case UNION has 
duplicates just like it should.

I will also have a look at second query.

> SQL query with COUNT and UNION in sub-query produces JdbcSQLException
> -
>
> Key: IGNITE-7785
> URL: https://issues.apache.org/jira/browse/IGNITE-7785
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
>  CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
>  INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
>  INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL Query:
> SELECT count(1) FROM person p
>  LEFT JOIN (select id from company union select id from company) as c on 
> c.id=p.company_id
> JDBC Exception:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
> the GROUP BY list; SQL statement:
> SELECT
> P__Z0.COMPANY_ID __C0_0,
> COUNT(1) __C0_1
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7646) OSGI tests fail to unlock build directory causing following builds to fail to start

2018-02-27 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur commented on IGNITE-7646:


[~dpavlov], thanks for the related issue link.

I will look at build's result. If it got the described (in this ticket) 
exception then I'll try to fix it. 
 Otherwise, it needs to be specified what this task is about.

 

 

> OSGI tests fail to unlock build directory causing following builds to fail to 
> start
> ---
>
> Key: IGNITE-7646
> URL: https://issues.apache.org/jira/browse/IGNITE-7646
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> After running test suite [Ignite Tests 2.4+ \[Java 8\] Ignite 
> OSGi|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteOSGi]
>  under Windows based agent, following builds fail to start with error
> {code}
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle1\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle2\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle3\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle4\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle5\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle6\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle7\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle8\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\cache.lock
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\log\karaf.log
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.diagnostic.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.jaas.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.main-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.osgi.core-6.0.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\javax.annotation-api-1.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.karaf.exception-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-2.7.2_2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-serializer-2.7.2_1.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.activation-api-1.1-2.5.0.jar
> [16:30:24]Failed to delete file: 
> 

[jira] [Commented] (IGNITE-6156) ODBC: Implement SQL_ATTR_QUERY_TIMEOUT statement attribute

2018-02-27 Thread Igor Sapego (JIRA)

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

Igor Sapego commented on IGNITE-6156:
-

Closed as a duplicate of a IGNITE-6836

> ODBC: Implement SQL_ATTR_QUERY_TIMEOUT statement attribute
> --
>
> Key: IGNITE-6156
> URL: https://issues.apache.org/jira/browse/IGNITE-6156
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.4
>
>
> Need to implement {{SQL_ATTR_QUERY_TIMEOUT}} statement attribute. See 
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlsetstmtattr-function
>  for details.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-6156) ODBC: Implement SQL_ATTR_QUERY_TIMEOUT statement attribute

2018-02-27 Thread Igor Sapego (JIRA)

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

Igor Sapego resolved IGNITE-6156.
-
   Resolution: Duplicate
 Assignee: Igor Sapego
Fix Version/s: 2.4

> ODBC: Implement SQL_ATTR_QUERY_TIMEOUT statement attribute
> --
>
> Key: IGNITE-6156
> URL: https://issues.apache.org/jira/browse/IGNITE-6156
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.4
>
>
> Need to implement {{SQL_ATTR_QUERY_TIMEOUT}} statement attribute. See 
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlsetstmtattr-function
>  for details.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7646) OSGI tests fail to unlock build directory causing following builds to fail to start

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov commented on IGNITE-7646:


[~daradurvs], test fail itself is being fixed under 
https://issues.apache.org/jira/browse/IGNITE-7814

This issue is relared to not released files on FS for Windows.

> OSGI tests fail to unlock build directory causing following builds to fail to 
> start
> ---
>
> Key: IGNITE-7646
> URL: https://issues.apache.org/jira/browse/IGNITE-7646
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> After running test suite [Ignite Tests 2.4+ \[Java 8\] Ignite 
> OSGi|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteOSGi]
>  under Windows based agent, following builds fail to start with error
> {code}
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle1\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle2\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle3\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle4\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle5\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle6\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle7\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle8\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\cache.lock
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\log\karaf.log
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.diagnostic.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.jaas.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.main-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.osgi.core-6.0.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\javax.annotation-api-1.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.karaf.exception-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-2.7.2_2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-serializer-2.7.2_1.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.activation-api-1.1-2.5.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.jaxb-api-2.2-2.5.0.jar
> [16:30:24]Failed to delete file: 
> 

[jira] [Commented] (IGNITE-7646) OSGI tests fail to unlock build directory causing following builds to fail to start

2018-02-27 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur commented on IGNITE-7646:


[https://ci.ignite.apache.org/viewLog.html?buildId=1086861=buildResultsDiv=IgniteTests24Java8_IgniteOSGi]

At the moment, it fails with following error:
{noformat}
java.rmi.NotBoundException: 604547bf-1f9d-4cdd-8d91-15c7800b33f1
--- Stdout: ---
2018-02-27 08:42:08,090 | INFO | FelixStartLevel | fileinstall | 4 - 
org.apache.felix.fileinstall - 3.5.0 | Creating configuration from 
org.apache.karaf.features.repos.cfg
2018-02-27 08:42:09,933 | INFO | pool-7-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Adding features: 
test-dependencies/[0,0.0.0], instance/[4.0.2,4.0.2], package/[4.0.2,4.0.2], 
log/[4.0.2,4.0.2], ssh/[4.0.2,4.0.2], 
ignite-hibernate/[2.5.0.SNAPSHOT,2.5.0.SNAPSHOT], 
aries-blueprint/[4.0.2,4.0.2], exam/[4.6.0,4.6.0], 
ignite-all/[2.5.0.SNAPSHOT,2.5.0.SNAPSHOT], system/[4.0.2,4.0.2], 
feature/[4.0.2,4.0.2], management/[4.0.2,4.0.2], shell/[4.0.2,4.0.2], 
service/[4.0.2,4.0.2], jaas/[4.0.2,4.0.2], deployer/[4.0.2,4.0.2], 
diagnostic/[4.0.2,4.0.2], shell-compat/[4.0.2,4.0.2], bundle/[4.0.2,4.0.2], 
config/[4.0.2,4.0.2], kar/[4.0.2,4.0.2], wrap/[0,0.0.0]
2018-02-27 08:42:10,230 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Changes to perform:
2018-02-27 08:42:10,231 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Region: root
2018-02-27 08:42:10,231 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Bundles to install:
2018-02-27 08:42:10,231 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | 
mvn:org.ops4j.pax.url/pax-url-wrap/2.4.3/jar/uber
2018-02-27 08:42:10,233 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Installing bundles:
2018-02-27 08:42:10,234 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | 
mvn:org.ops4j.pax.url/pax-url-wrap/2.4.3/jar/uber
2018-02-27 08:42:10,340 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Starting bundles:
2018-02-27 08:42:10,343 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | org.ops4j.pax.url.wrap/2.4.3
2018-02-27 08:42:10,361 | INFO | pool-8-thread-1 | FeaturesServiceImpl | 8 - 
org.apache.karaf.features.core - 4.0.2 | Done.
2018-02-27 08:43:55,818 | ERROR | pool-7-thread-1 | BootFeaturesInstaller | 8 - 
org.apache.karaf.features.core - 4.0.2 | Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error
at 
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:358)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:355)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:191)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[8:org.apache.karaf.features.core:4.0.2]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[8:org.apache.karaf.features.core:4.0.2]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_77]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_77]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
Caused by: java.io.IOException: Error downloading 
file:/home/teamcity/.m2/repository/org/scala-lang/scala-library/2.13.0-M3/scala-library-2.13.0-M3.jar${scala211.library.version}
at 
org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:67)[8:org.apache.karaf.features.core:4.0.2]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_77]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_77]
at 

[jira] [Commented] (IGNITE-7646) OSGI tests fail to unlock build directory causing following builds to fail to start

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7646:


GitHub user daradurvs opened a pull request:

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

IGNITE-7646 OSGI tests fail



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

$ git pull https://github.com/daradurvs/ignite ignite-7646

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

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


commit 9f8c6d7d9528c66e8ee0dcb82cb8b59fb1fc45ff
Author: Vyacheslav Daradur 
Date:   2018-02-27T12:15:49Z

ignite-7646: fix property name




> OSGI tests fail to unlock build directory causing following builds to fail to 
> start
> ---
>
> Key: IGNITE-7646
> URL: https://issues.apache.org/jira/browse/IGNITE-7646
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> After running test suite [Ignite Tests 2.4+ \[Java 8\] Ignite 
> OSGi|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteOSGi]
>  under Windows based agent, following builds fail to start with error
> {code}
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle1\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle2\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle3\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle4\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle5\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle6\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle7\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle8\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\cache.lock
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\log\karaf.log
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.diagnostic.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.jaas.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.main-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.osgi.core-6.0.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\javax.annotation-api-1.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.karaf.exception-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-2.7.2_2.jar
> [16:30:24]Failed to delete file: 
> 

[jira] [Assigned] (IGNITE-7646) OSGI tests fail to unlock build directory causing following builds to fail to start

2018-02-27 Thread Vyacheslav Daradur (JIRA)

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

Vyacheslav Daradur reassigned IGNITE-7646:
--

Assignee: Vyacheslav Daradur

> OSGI tests fail to unlock build directory causing following builds to fail to 
> start
> ---
>
> Key: IGNITE-7646
> URL: https://issues.apache.org/jira/browse/IGNITE-7646
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> After running test suite [Ignite Tests 2.4+ \[Java 8\] Ignite 
> OSGi|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteOSGi]
>  under Windows based agent, following builds fail to start with error
> {code}
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle1\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle2\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle3\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle4\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle5\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle6\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle7\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\bundle8\version0.0\bundle.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\cache\cache.lock
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\data\log\karaf.log
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.diagnostic.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.jaas.boot-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.apache.karaf.main-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\boot\org.osgi.core-6.0.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\javax.annotation-api-1.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.karaf.exception-4.0.2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-2.7.2_2.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.bundles.xalan-serializer-2.7.2_1.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.activation-api-1.1-2.5.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.jaxb-api-2.2-2.5.0.jar
> [16:30:24]Failed to delete file: 
> C:\BuildAgent\work\bd85361428dcdb1\modules\osgi\target\paxexam\unpack\f12af441-dfed-411b-9784-87dafedfac4f\lib\endorsed\org.apache.servicemix.specs.jaxp-api-1.4-2.5.0.jar

[jira] [Updated] (IGNITE-7821) Update Apache Ignite and Web Console Dockerfile for 2.4 version and local build

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov updated IGNITE-7821:
-
Priority: Critical  (was: Major)

> Update Apache Ignite and Web Console Dockerfile for 2.4 version and local 
> build
> ---
>
> Key: IGNITE-7821
> URL: https://issues.apache.org/jira/browse/IGNITE-7821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.4
>
>
> # Update Dockerfiles in order to match upcoming 2.4 release.
> # Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7824) Rollback part of IGNITE-7170 changes

2018-02-27 Thread Alexey Popov (JIRA)
Alexey Popov created IGNITE-7824:


 Summary: Rollback part of IGNITE-7170 changes
 Key: IGNITE-7824
 URL: https://issues.apache.org/jira/browse/IGNITE-7824
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Alexey Popov


Please rollback changes done by mistake:

U.quietAndWarn(log, "Nodes started on local machine require 
more than 20% of physical RAM what can " +

back to:

U.quietAndWarn(log, "Nodes started on local machine require 
more than 80% of physical RAM what can " +




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7821) Update Apache Ignite and Web Console Dockerfile for 2.4 version and local build

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7821:


GitHub user vveider opened a pull request:

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

IGNITE-7821 Update Apache Ignite and Web Console Dockerfile for 2.4 version 
and local build

 * removed Apache Ignite's Docker module obsolete autobuild directory layout
 * updated Apache Ignite's Dockerfile for local image build and use of 
lighter base image
 * removed Web Console's build script - replaced with pre-build instructions
 * introduced minor refactoring to Web Console's Dockerfile
 * fixed .dockerignore file with correct paths

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

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

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

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


commit ca9077dc6f56e62ef3dfe251d5e3477da929074a
Author: Ivanov Petr 
Date:   2018-02-27T09:10:57Z

IGNITE-7821 Update Apache Ignite and Web Console Dockerfile for 2.4 version 
and local build
 * removed Apache Ignite's Docker module obsolete autobuild directory layout
 * updated Apache Ignite's Dockerfile for local image build and use of 
lighter base image
 * removed Web Console's build script - replaced with pre-build instructions
 * introduced minor refactoring to Web Console's Dockerfile
 * fixed .dockerignore file with correct paths




> Update Apache Ignite and Web Console Dockerfile for 2.4 version and local 
> build
> ---
>
> Key: IGNITE-7821
> URL: https://issues.apache.org/jira/browse/IGNITE-7821
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.4
>
>
> # Update Dockerfiles in order to match upcoming 2.4 release.
> # Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7823) Enrich IgniteCache with asSet method

2018-02-27 Thread Andrey Kuznetsov (JIRA)
Andrey Kuznetsov created IGNITE-7823:


 Summary: Enrich IgniteCache with asSet method
 Key: IGNITE-7823
 URL: https://issues.apache.org/jira/browse/IGNITE-7823
 Project: Ignite
  Issue Type: New Feature
  Components: data structures
Reporter: Andrey Kuznetsov
 Fix For: 2.5


Existing {{IgniteSet}} datastructure is good enough for small sets. For big 
sets it's too expensive to maintain redundant onheap data copies. Thus we'd 
better to add new {{IgniteCache::asSet}} method returning set adapter to 
existing cache. The difference between these two kinds of sets should be 
properly documented afterwards. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov commented on IGNITE-7816:
-

[~dmagda] I've moved DataFrame examples to 
{{org.apache.ignite.scalar.examples.spark}} package. 
Please, take a look at my changes.

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-02-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-7816:


GitHub user nizhikov opened a pull request:

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

IGNITE-7816: DataFrame examples fixed.

 moved to `org.apache.ignite.scalar.examples.spark` package. Minor examples 
improvements.

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

$ git pull https://github.com/nizhikov/ignite IGNITE-7816

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

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


commit 7c89b4b2d1bc03c0790862826d83777ba31fe0df
Author: Nikolay Izhikov 
Date:   2018-02-27T10:26:39Z

IGNITE-7816: DataFrame examples moved to 
`org.apache.ignite.scalar.examples.spark` package. Minor examples improvements.




> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7822) SQL Query with with union and left join produces "Column not found" error

2018-02-27 Thread Pavel Vinokurov (JIRA)
Pavel Vinokurov created IGNITE-7822:
---

 Summary: SQL Query with with union and left join produces "Column 
not found" error
 Key: IGNITE-7822
 URL: https://issues.apache.org/jira/browse/IGNITE-7822
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3, 2.1
Reporter: Pavel Vinokurov


 
 
Initial script:
 
CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary 
DECIMAL);
CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR);
CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, 
market_value DECIMAL);
INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), 
(3, 3, 300);
INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3');
INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 1), 
(2, 2, 2), (3, 3, 3); CREATE TABLE Address (id INTEGER PRIMARY KEY, 
person_id INTEGER, city VARCHAR);INSERT INTO Person (id, company_id, salary) 
VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300);INSERT INTO Address (id, 
person_id, city) VALUES (1, 1, 'san francisco'), (2, 2, 'paris'), (3, 3, 'new 
york');INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 
'n3');INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 
1), (2, 2, 2), (3, 3, 3);
 
Query:
SELECT a.idFROM  (SELECT     p1.id as pid,     p1.salary,     p1.company_id   
FROM Person p1   WHERE p1.id = 1   UNION   SELECT     p2.id as pid,     
p2.salary,     p2.company_id   FROM Person p2   WHERE p2.id = 2)  p  LEFT JOIN 
Company c ON p.company_id = c.id  LEFT JOIN Company_Value cv ON c.id = 
cv.company_id  LEFT JOIN Address a ON a.person_id = p.pid;
 
Result:
Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not found; 
SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3  LEFT OUTER JOIN 
PUBLIC.COMPANY_VALUE CV__Z4  ON C__Z3.ID = CV__Z4.COMPANY_ID  LEFT OUTER JOIN 
PUBLIC.ADDRESS A__Z5  ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 [42122-195]
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

2018-02-27 Thread Pavel Kovalenko (JIRA)

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

Pavel Kovalenko commented on IGNITE-7717:
-

[~agoncharuk] Fix is reworked. Could you please re-check it?

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-6809) Use MPSC queue in striped pool

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-6809:

Fix Version/s: (was: 2.4)

> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-6809) Use MPSC queue in striped pool

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov edited comment on IGNITE-6809 at 2/27/18 9:42 AM:
--

Reopened ticket because suggested change causes consistent performance drop in 
cache benchmarks when executed on AWS. Need to investigate further. Commit has 
been reverted from master. Please use this commit for investigation:
6f94659b53f056c176b3a3c6dd8f11a5db2ad74f IGNITE-6809: Use MPSC queue in striped 
pool. This closes #2960. Igor Seliverstov* 11/7/2017 12:02 PM


was (Author: vozerov):
Reopened ticket because suggested change causes consistent performance drop in 
cache benchmarks when executed on AWS. Need to investigate further. Commit has 
been reverted from master. Please use this commit for investigation:
{{6f94659b53f056c176b3a3c6dd8f11a5db2ad74f IGNITE-6809: Use MPSC queue in 
striped pool. This closes #2960. Igor Seliverstov* 11/7/2017 12:02 PM }}

> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
> Fix For: 2.4
>
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-6809) Use MPSC queue in striped pool

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov edited comment on IGNITE-6809 at 2/27/18 9:42 AM:
--

Reopened ticket because suggested change causes consistent performance drop in 
cache benchmarks when executed on AWS. Need to investigate further. Commit has 
been reverted from master. Please use this commit for investigation:

6f94659b53f056c176b3a3c6dd8f11a5db2ad74f IGNITE-6809: Use MPSC queue in striped 
pool. This closes #2960. Igor Seliverstov* 11/7/2017 12:02 PM


was (Author: vozerov):
Reopened ticket because suggested change causes consistent performance drop in 
cache benchmarks when executed on AWS. Need to investigate further. Commit has 
been reverted from master. Please use this commit for investigation:
6f94659b53f056c176b3a3c6dd8f11a5db2ad74f IGNITE-6809: Use MPSC queue in striped 
pool. This closes #2960. Igor Seliverstov* 11/7/2017 12:02 PM

> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
> Fix For: 2.4
>
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-6809) Use MPSC queue in striped pool

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-6809:
-

Reopened ticket because suggested change causes consistent performance drop in 
cache benchmarks when executed on AWS. Need to investigate further. Commit has 
been reverted from master. Please use this commit for investigation:
{{6f94659b53f056c176b3a3c6dd8f11a5db2ad74f IGNITE-6809: Use MPSC queue in 
striped pool. This closes #2960. Igor Seliverstov* 11/7/2017 12:02 PM }}

> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
> Fix For: 2.4
>
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (IGNITE-6809) Use MPSC queue in striped pool

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reopened IGNITE-6809:
-

> Use MPSC queue in striped pool
> --
>
> Key: IGNITE-6809
> URL: https://issues.apache.org/jira/browse/IGNITE-6809
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
>  Labels: performance
> Fix For: 2.4
>
>
> Use MPSC queue in striped pool
> Let's start from [MP-SC concurrent linked queue implementation based on 
> Dmitry 
> Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7812) Slow rebalancing in case of enabled persistence

2018-02-27 Thread Pavel Kovalenko (JIRA)

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

Pavel Kovalenko reassigned IGNITE-7812:
---

Assignee: Pavel Kovalenko

> Slow rebalancing in case of enabled persistence
> ---
>
> Key: IGNITE-7812
> URL: https://issues.apache.org/jira/browse/IGNITE-7812
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
>
> A user reported that rebalancing take significantly larger amounts of time 
> when persistence is enabled even in LOG_ONLY mode.
> Need to investigate how the performance of rebalancing may be increased.
> Also, it would be great to estimate the benefit of file transfer for 
> rebalancing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7819) IgniteServiceConfigVariationsFullApiTest must stop services in finally block

2018-02-27 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk updated IGNITE-7819:
-
Labels: MakeTeamcityGreenAgain  (was: )

> IgniteServiceConfigVariationsFullApiTest must stop services in finally block
> 
>
> Key: IGNITE-7819
> URL: https://issues.apache.org/jira/browse/IGNITE-7819
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Currently the test is flaky, however when it fails, not calling undeploy in a 
> finally block will lead to all subsequent tests to fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7818) Incorrect assertion in PDS page eviction method

2018-02-27 Thread Dmitriy Pavlov (JIRA)

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

Dmitriy Pavlov updated IGNITE-7818:
---
Component/s: persistence

> Incorrect assertion in PDS page eviction method
> ---
>
> Key: IGNITE-7818
> URL: https://issues.apache.org/jira/browse/IGNITE-7818
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> There is an assertion in the method 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
>  
> {code:java}
> assert relRmvAddr != INVALID_REL_PTR;{code}
> Which seems potentially dangerous. In some rare cases, when count of 
> interations more then 40% of allocated pages and all processed pages are 
> aquired, the {{relRmvAddr}} variable will be uninitialized and 
> {{AssertionException}} will be thrown. But it's a correct case and page to 
> evict can be found later in the method {{tryToFindSequentially.}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-7253:
-

Re-opened a ticket, as we agreed that it is better to implement dynamic 
streaming instead of current "static" approach. Commits were reverted from the 
{{master}} branch. Changes are assembled into a single patch, see attached.

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7253) JDBC thin driver: introduce streaming mode

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-7253:

Attachment: IGNITE_7253.patch

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7820) Investigate and fix perfromance drop of WAL for FSYNC mode

2018-02-27 Thread Andrey Gura (JIRA)

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

Andrey Gura updated IGNITE-7820:

Description: 
WAL performance drop was introduced by 
https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
better performance for {{FSYNC}} WAL mode {{FsyncModeFileWriteAheadLogManager}} 
implementation was added as result of fix issue 
https://issues.apache.org/jira/browse/IGNITE-7594.

*What we know about this performance drop:*

* It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
measurements show 10-15% drop and ~50% drop accordingly.
* It is reproducible not for all hardware configuration. That is for some 
configuration we see performance improvements instead of drop.
* It is reproducible for [Many clients --> One server] topology.
* If {{IGNITE_WAL_MMAP == false}} then we have better performance.
* If {{fsyncDelay == 0}} then we have better performance.

*What were tried during initial investigation:*

* Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
2%.
* Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
{{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
benchmarks.

*What should we do:*

Investigate the problem and provide fix or recommendation for system tuning.

  was:
WAL performance drop was introduced by 
https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
better performance for {{DEFAULT}} WAL mode 
{{FsyncModeFileWriteAheadLogManager}} implementation was added as result of fix 
issue https://issues.apache.org/jira/browse/IGNITE-7594.

What we know about this performance drop:

* It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
measurements show 10-15% drop and ~50% drop accordingly.
* It is reproducible not for all hardware configuration. That is for some 
configuration we see only performance improvements instead of drop.
* It is reproducible for [Many clients --> One server] topology.
* If {{IGNITE_WAL_MMAP == false}} then we have better performance.
* If {{fsyncDelay == 0}} then we have better performance.

What were tried during initial investigation:

* Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
2%.
* Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
{{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
benchmarks.

What should we do:

Investigate the problem and provide fix or recommendation for system tuning.


> Investigate and fix perfromance drop of WAL for FSYNC mode
> --
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> WAL performance drop was introduced by 
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
> better performance for {{FSYNC}} WAL mode 
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of 
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> *What we know about this performance drop:*
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some 
> configuration we see performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> *What were tried during initial investigation:*
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
> benchmarks.
> *What should we do:*
> Investigate the problem and provide fix or recommendation for system tuning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7820) Investigate and fix perfromance drop of WAL for FSYNC mode

2018-02-27 Thread Andrey Gura (JIRA)

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

Andrey Gura updated IGNITE-7820:

Summary: Investigate and fix perfromance drop of WAL for FSYNC mode  (was: 
Investigate and fix perfromance drop of WAL for default mode)

> Investigate and fix perfromance drop of WAL for FSYNC mode
> --
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> WAL performance drop was introduced by 
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
> better performance for {{DEFAULT}} WAL mode 
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of 
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> What we know about this performance drop:
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some 
> configuration we see only performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> What were tried during initial investigation:
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
> benchmarks.
> What should we do:
> Investigate the problem and provide fix or recommendation for system tuning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7821) Update Apache Ignite and Web Console Dockerfile for 2.4 version and local build

2018-02-27 Thread Peter Ivanov (JIRA)
Peter Ivanov created IGNITE-7821:


 Summary: Update Apache Ignite and Web Console Dockerfile for 2.4 
version and local build
 Key: IGNITE-7821
 URL: https://issues.apache.org/jira/browse/IGNITE-7821
 Project: Ignite
  Issue Type: Improvement
Reporter: Peter Ivanov
Assignee: Peter Ivanov
 Fix For: 2.4


# Update Dockerfiles in order to match upcoming 2.4 release.
# Change Apache Ignite's Dockerfile to get binaries from local build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IGNITE-7808) Automate Docker images build

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov closed IGNITE-7808.


> Automate Docker images build
> 
>
> Key: IGNITE-7808
> URL: https://issues.apache.org/jira/browse/IGNITE-7808
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> Introduce and document process and tools for automated Docked images build 
> based on release tag. Include both Ignite and Web Console images.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-7808) Automate Docker images build

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov resolved IGNITE-7808.
--
Resolution: Won't Fix

> Automate Docker images build
> 
>
> Key: IGNITE-7808
> URL: https://issues.apache.org/jira/browse/IGNITE-7808
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> Introduce and document process and tools for automated Docked images build 
> based on release tag. Include both Ignite and Web Console images.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7808) Automate Docker images build

2018-02-27 Thread Peter Ivanov (JIRA)

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

Peter Ivanov commented on IGNITE-7808:
--

Since Apache Ignite and Web Console Docker images should be included into QA 
process and be available during release phase as prepared binaries, the focus 
will be moved to modifying corresponding Dockerfiles for preparing local images.

> Automate Docker images build
> 
>
> Key: IGNITE-7808
> URL: https://issues.apache.org/jira/browse/IGNITE-7808
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> Introduce and document process and tools for automated Docked images build 
> based on release tag. Include both Ignite and Web Console images.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (IGNITE-7253) JDBC thin driver: introduce streaming mode

2018-02-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov reopened IGNITE-7253:
-

> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation

2018-02-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-7462:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7820) Investigate and fix perfromance drop of WAL for default mode

2018-02-27 Thread Andrey Gura (JIRA)

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

Andrey Gura reassigned IGNITE-7820:
---

Assignee: Andrey Gura

> Investigate and fix perfromance drop of WAL for default mode
> 
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> WAL performance drop was introduced by 
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
> better performance for {{DEFAULT}} WAL mode 
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of 
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> What we know about this performance drop:
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some 
> configuration we see only performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> What were tried during initial investigation:
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
> benchmarks.
> What should we do:
> Investigate the problem and provide fix or recommendation for system tuning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-7594) Tx performance drop after WAL optimization

2018-02-27 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-7594:
-

Thanks, Ilya. I created new ticket for performance drop investigation: 
https://issues.apache.org/jira/browse/IGNITE-7820

> Tx performance drop after WAL optimization 
> ---
>
> Key: IGNITE-7594
> URL: https://issues.apache.org/jira/browse/IGNITE-7594
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Aleksey Chetaev
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.4
>
>
> Perfomance dropes in tx-putAll benchmarks after commit with WAL optimization.
> WAL Mode: Default
> First bad commit: 
> [https://github.com/apache/ignite/commit/a5ffd4eb18e6e9eab30c176a7bb4008a51b3d59d]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7820) Investigate and fix perfromance drop of WAL for default mode

2018-02-27 Thread Andrey Gura (JIRA)
Andrey Gura created IGNITE-7820:
---

 Summary: Investigate and fix perfromance drop of WAL for default 
mode
 Key: IGNITE-7820
 URL: https://issues.apache.org/jira/browse/IGNITE-7820
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Gura
 Fix For: 2.5


WAL performance drop was introduced by 
https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
better performance for {{DEFAULT}} WAL mode 
{{FsyncModeFileWriteAheadLogManager}} implementation was added as result of fix 
issue https://issues.apache.org/jira/browse/IGNITE-7594.

What we know about this performance drop:

* It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
measurements show 10-15% drop and ~50% drop accordingly.
* It is reproducible not for all hardware configuration. That is for some 
configuration we see only performance improvements instead of drop.
* It is reproducible for [Many clients --> One server] topology.
* If {{IGNITE_WAL_MMAP == false}} then we have better performance.
* If {{fsyncDelay == 0}} then we have better performance.

What were tried during initial investigation:

* Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
2%.
* Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
{{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
benchmarks.

What should we do:

Investigate the problem and provide fix or recommendation for system tuning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

2018-02-27 Thread Nikolay Izhikov (JIRA)

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

Nikolay Izhikov reassigned IGNITE-7655:
---

Assignee: Akmal Chaudhri  (was: Nikolay Izhikov)

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Akmal Chaudhri
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-7819) IgniteServiceConfigVariationsFullApiTest must stop services in finally block

2018-02-27 Thread Alexey Goncharuk (JIRA)
Alexey Goncharuk created IGNITE-7819:


 Summary: IgniteServiceConfigVariationsFullApiTest must stop 
services in finally block
 Key: IGNITE-7819
 URL: https://issues.apache.org/jira/browse/IGNITE-7819
 Project: Ignite
  Issue Type: Test
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-7819) IgniteServiceConfigVariationsFullApiTest must stop services in finally block

2018-02-27 Thread Alexey Goncharuk (JIRA)

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

Alexey Goncharuk updated IGNITE-7819:
-
Description: Currently the test is flaky, however when it fails, not 
calling undeploy in a finally block will lead to all subsequent tests to fail.

> IgniteServiceConfigVariationsFullApiTest must stop services in finally block
> 
>
> Key: IGNITE-7819
> URL: https://issues.apache.org/jira/browse/IGNITE-7819
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> Currently the test is flaky, however when it fails, not calling undeploy in a 
> finally block will lead to all subsequent tests to fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)