[jira] [Updated] (IGNITE-7830) Adopt kNN regression model to the new Partitioned Dataset
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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 PlekhanovDate: 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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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 LukjanenkoDate: 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
[ 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
[ 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 PlekhanovDate: 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
[ 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
[ 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
[ 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
[ 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
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
[ 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 KovalenkoDate: 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
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.
[ 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.
[ 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
[ 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.
[ 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.
[ 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.
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
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
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
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
[ 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
[ 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: zaleslawDate: 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
[ 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
[ 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
[ 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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 DaradurDate: 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
[ 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
[ 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
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
[ 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 PetrDate: 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
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
[ 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
[ 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 IzhikovDate: 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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)