[jira] [Commented] (IGNITE-9732) Add joins to Spark Dataframe examples
[
https://issues.apache.org/jira/browse/IGNITE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631389#comment-16631389
]
Vladimir Ozerov commented on IGNITE-9732:
-
[~vkulichenko], we almost reached code freeze for AI 2.7. Will you be able to
complete it by 30 Sept 2018?
> Add joins to Spark Dataframe examples
> -
>
> Key: IGNITE-9732
> URL: https://issues.apache.org/jira/browse/IGNITE-9732
> Project: Ignite
> Issue Type: Improvement
> Components: examples, spark
>Affects Versions: 2.6
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.7
>
>
> {{IgniteDataFrameExample}} creates two tables - {{city}} and {{person}}, but
> only {{person}} is actually used. Need to add join examples.
> Would also be great to demonstrate the fact that optimization is working and
> joins are executed in Ignite, not Spark (using {{explain()}}, maybe?).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6862) SparseDistributedMatrixStorage cache config possibly allows read of old state of matrix
[ https://issues.apache.org/jira/browse/IGNITE-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6862: Fix Version/s: (was: 2.7) 2.8 > SparseDistributedMatrixStorage cache config possibly allows read of old > state of matrix > > > Key: IGNITE-6862 > URL: https://issues.apache.org/jira/browse/IGNITE-6862 > Project: Ignite > Issue Type: Bug >Reporter: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Because synchronization mode is PRIMARY_SYNC, but by default we have > readFromBackup=true, we can read old state of matrix from backups. It seem to > be an issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6862) SparseDistributedMatrixStorage cache config possibly allows read of old state of matrix
[ https://issues.apache.org/jira/browse/IGNITE-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631388#comment-16631388 ] Vladimir Ozerov commented on IGNITE-6862: - Moved to AI 2.8 due to inactivity. Please feel free to return the ticket to 2.7 if it is ready by 30 Sep 2018. > SparseDistributedMatrixStorage cache config possibly allows read of old > state of matrix > > > Key: IGNITE-6862 > URL: https://issues.apache.org/jira/browse/IGNITE-6862 > Project: Ignite > Issue Type: Bug >Reporter: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Because synchronization mode is PRIMARY_SYNC, but by default we have > readFromBackup=true, we can read old state of matrix from backups. It seem to > be an issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7065) Cannot use multiple Ignite Kafka Sink Connectors
[ https://issues.apache.org/jira/browse/IGNITE-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7065: Fix Version/s: (was: 2.7) 2.8 > Cannot use multiple Ignite Kafka Sink Connectors > - > > Key: IGNITE-7065 > URL: https://issues.apache.org/jira/browse/IGNITE-7065 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Priority: Major > Fix For: 2.8 > > > Stopping an Ignite Kafka sink connector makes other connectors deployed in > the same worker unusable. As a result we cannot stream different topics in > different caches since connector support streaming to single cache only. > See > http://apache-ignite-users.70518.x6.nabble.com/Issues-with-multiple-kafka-connectors-questions-regarding-ignite-caches-tc18297.html > for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7065) Cannot use multiple Ignite Kafka Sink Connectors
[ https://issues.apache.org/jira/browse/IGNITE-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631386#comment-16631386 ] Vladimir Ozerov commented on IGNITE-7065: - Moved to AI 2.8 due to inactivity. Please feel free to return the ticket to 2.7 if it is ready by 30 Sep 2018. > Cannot use multiple Ignite Kafka Sink Connectors > - > > Key: IGNITE-7065 > URL: https://issues.apache.org/jira/browse/IGNITE-7065 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Priority: Major > Fix For: 2.8 > > > Stopping an Ignite Kafka sink connector makes other connectors deployed in > the same worker unusable. As a result we cannot stream different topics in > different caches since connector support streaming to single cache only. > See > http://apache-ignite-users.70518.x6.nabble.com/Issues-with-multiple-kafka-connectors-questions-regarding-ignite-caches-tc18297.html > for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8098) Getting affinity for topology version earlier than affinity is calculated because of data race
[
https://issues.apache.org/jira/browse/IGNITE-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8098:
Fix Version/s: (was: 2.7)
2.8
> Getting affinity for topology version earlier than affinity is calculated
> because of data race
> --
>
> Key: IGNITE-8098
> URL: https://issues.apache.org/jira/browse/IGNITE-8098
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrey Aleksandrov
>Priority: Minor
> Fix For: 2.8
>
>
> From time to time the Ignite cluster with services throws next exception
> during restarting of some nodes:
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=c770dbcf-2908-442d-8aa0-bf26a2aecfef, addrs=[10.44.162.169, 127.0.0.1],
> sockAddrs=[clrv041279.ic.ing.net/10.44.162.169:56500, /127.0.0.1:56500],
> discPort=56500, order=11, intOrder=8, lastExchangeTime=1520931375337,
> loc=true, ver=2.3.3#20180213-sha1:f446df34, isClient=false],
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=15, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=11, minorTopVer=0],
> AffinityTopologyVersion [topVer=11, minorTopVer=1], AffinityTopologyVersion
> [topVer=12, minorTopVer=0], AffinityTopologyVersion [topVer=15,
> minorTopVer=0]]]
> Looks like the reason of this issue is the data race in GridServiceProcessor
> class.
> How to reproduce:
> 1)To simulate data race you should update next place in source code:
> Class: GridServiceProcessor
> Method: @Override public void onEvent(final DiscoveryEvent evt, final
> DiscoCache discoCache) {
> Place:
>
> try {
> svcName.set(dep.configuration().getName());
> ctx.cache().internalCache(UTILITY_CACHE_NAME).context().affinity().
> affinityReadyFuture(topVer).get();
> //HERE (between GET and REASSIGN) you should add Thread.sleep(100) for
> example.
> //try {
> //Thread.sleep(100);
> //}
> //catch (InterruptedException e1) {
> //e1.printStackTrace();
> //}
>
> reassign(dep, topVer);
> }
> catch (IgniteCheckedException ex) {
> if (!(e instanceof ClusterTopologyCheckedException))
> LT.error(log, ex, "Failed to do service reassignment (will retry): " +
> dep.configuration().getName());
> retries.add(dep);
> }
> ...
> 2)After that you should imitate start/shutdown iterations. For reproducing I
> used GridServiceProcessorBatchDeploySelfTest (but timeout on future.get
> should be increased to avoid timeout error)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7899) Write Zookeeper Discovery documentation in java docs
[ https://issues.apache.org/jira/browse/IGNITE-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7899: Fix Version/s: (was: 2.7) 2.8 > Write Zookeeper Discovery documentation in java docs > > > Key: IGNITE-7899 > URL: https://issues.apache.org/jira/browse/IGNITE-7899 > Project: Ignite > Issue Type: Task > Components: zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > Fix For: 2.8 > > > Describe Zookeeper Discovery in java docs -- 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
]
Vladimir Ozerov updated IGNITE-7651:
Fix Version/s: (was: 2.7)
2.8
> 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.8
>
>
> 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-7899) Write Zookeeper Discovery documentation in java docs
[ https://issues.apache.org/jira/browse/IGNITE-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631385#comment-16631385 ] Vladimir Ozerov commented on IGNITE-7899: - Moved to AI 2.8 due to inactivity, please feel free to return ticket back to 2.7 if it is ready by 30 Sep 2018 (AI 2.7 code freeze date). > Write Zookeeper Discovery documentation in java docs > > > Key: IGNITE-7899 > URL: https://issues.apache.org/jira/browse/IGNITE-7899 > Project: Ignite > Issue Type: Task > Components: zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > Fix For: 2.8 > > > Describe Zookeeper Discovery in java docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16631384#comment-16631384
]
Vladimir Ozerov commented on IGNITE-7651:
-
Moved to AI 2.8 due to inactivity, please feel free to return ticket back to
2.7 if it is ready by 30 Sep 2018 (AI 2.7 code freeze date).
> 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.8
>
>
> 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-8098) Getting affinity for topology version earlier than affinity is calculated because of data race
[
https://issues.apache.org/jira/browse/IGNITE-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631383#comment-16631383
]
Vladimir Ozerov commented on IGNITE-8098:
-
Moved to AI 2.8 due to inactivity, please feel free to return ticket back to
2.7 if it is ready by 30 Sep 2018 (AI 2.7 code freeze date).
> Getting affinity for topology version earlier than affinity is calculated
> because of data race
> --
>
> Key: IGNITE-8098
> URL: https://issues.apache.org/jira/browse/IGNITE-8098
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrey Aleksandrov
>Priority: Minor
> Fix For: 2.7
>
>
> From time to time the Ignite cluster with services throws next exception
> during restarting of some nodes:
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=c770dbcf-2908-442d-8aa0-bf26a2aecfef, addrs=[10.44.162.169, 127.0.0.1],
> sockAddrs=[clrv041279.ic.ing.net/10.44.162.169:56500, /127.0.0.1:56500],
> discPort=56500, order=11, intOrder=8, lastExchangeTime=1520931375337,
> loc=true, ver=2.3.3#20180213-sha1:f446df34, isClient=false],
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=15, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=11, minorTopVer=0],
> AffinityTopologyVersion [topVer=11, minorTopVer=1], AffinityTopologyVersion
> [topVer=12, minorTopVer=0], AffinityTopologyVersion [topVer=15,
> minorTopVer=0]]]
> Looks like the reason of this issue is the data race in GridServiceProcessor
> class.
> How to reproduce:
> 1)To simulate data race you should update next place in source code:
> Class: GridServiceProcessor
> Method: @Override public void onEvent(final DiscoveryEvent evt, final
> DiscoCache discoCache) {
> Place:
>
> try {
> svcName.set(dep.configuration().getName());
> ctx.cache().internalCache(UTILITY_CACHE_NAME).context().affinity().
> affinityReadyFuture(topVer).get();
> //HERE (between GET and REASSIGN) you should add Thread.sleep(100) for
> example.
> //try {
> //Thread.sleep(100);
> //}
> //catch (InterruptedException e1) {
> //e1.printStackTrace();
> //}
>
> reassign(dep, topVer);
> }
> catch (IgniteCheckedException ex) {
> if (!(e instanceof ClusterTopologyCheckedException))
> LT.error(log, ex, "Failed to do service reassignment (will retry): " +
> dep.configuration().getName());
> retries.add(dep);
> }
> ...
> 2)After that you should imitate start/shutdown iterations. For reproducing I
> used GridServiceProcessorBatchDeploySelfTest (but timeout on future.get
> should be increased to avoid timeout error)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631381#comment-16631381
]
Vladimir Ozerov commented on IGNITE-8630:
-
Moved to AI 2.8 due to inactivity, please feel free to return ticket back to
2.7 if it is ready by 30 Sep 2018 (AI 2.7 code freeze date).
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
> moment it's could be unexpected for the user.
> You can see the same behaviour during deploying of the caches with nodeFilter
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8630:
Fix Version/s: (was: 2.7)
2.8
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
> moment it's could be unexpected for the user.
> You can see the same behaviour during deploying of the caches with nodeFilter
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9165:
Fix Version/s: (was: 2.7)
2.8
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6677: Priority: Blocker (was: Major) > Collect QueryDetailMetrics for cache-less SQL queries > - > > Key: IGNITE-6677 > URL: https://issues.apache.org/jira/browse/IGNITE-6677 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Assignee: Evgenii Zhuravlev >Priority: Blocker > Fix For: 2.7 > > > We have logic that collect query history per caches. > We need: > # Add history size param on IgniteConfiguration > # Implement logic that will collect history for SQL queries executed directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods
[
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9160:
Fix Version/s: (was: 2.7)
2.8
> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object
> cannot be cast to
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> Or NPE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
> return false;{code}
> + List of classes with similar problems: +
> * *GridTopic$T1-T8* - NPE
> * *GridCachePreloadLifecycleAbstractTest -* NPE
> * *GridDhtPartitionFullMap -* NPE and CCE
> * *GridDhtPartitionMap -* NPE and CCE
> * *OptimizedMarshallerSelfTest -* NPE and CCE
> * *GatewayProtectedCacheProxy -* NPE and CCE
> * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
> * *GridCacheDistributedQueryManager -* NPE and CCE
> * *GridServiceMethodReflectKey -* NPE and CCE
> * *GridListSetSelfTest -* NPE and CCE
> * *GridTestKey -* NPE and CCE
> * *GridCacheMvccCandidate -* CCE
> * *GridDhtPartitionExchangeId -* CCE
> * *GridTuple6 -* CCE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631376#comment-16631376 ] Vladimir Ozerov commented on IGNITE-6677: - Raised priority to BLOCKER as we have many users complained about broken metrics. > Collect QueryDetailMetrics for cache-less SQL queries > - > > Key: IGNITE-6677 > URL: https://issues.apache.org/jira/browse/IGNITE-6677 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Assignee: Evgenii Zhuravlev >Priority: Blocker > Fix For: 2.7 > > > We have logic that collect query history per caches. > We need: > # Add history size param on IgniteConfiguration > # Implement logic that will collect history for SQL queries executed directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9303:
Fix Version/s: (was: 2.7)
2.8
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7136) .NET: IndexesAllocatedPages metrics
[ https://issues.apache.org/jira/browse/IGNITE-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7136: Fix Version/s: (was: 2.7) 2.8 > .NET: IndexesAllocatedPages metrics > --- > > Key: IGNITE-7136 > URL: https://issues.apache.org/jira/browse/IGNITE-7136 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Nikolay Izhikov >Priority: Major > Labels: .NET, iep-6 > Fix For: 2.8 > > > New JMX metric implemented in IGNITE-6903. > We need to add support for this metric to .Net -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9478) SQL: throw reducer retry error
[
https://issues.apache.org/jira/browse/IGNITE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9478:
Fix Version/s: (was: 2.7)
2.8
> SQL: throw reducer retry error
> --
>
> Key: IGNITE-9478
> URL: https://issues.apache.org/jira/browse/IGNITE-9478
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
>
> Currently we cannot pass correct error message from reducer retry condition
> to user exception. Need to fix that. See
> \{{GridReduceQueryExecutor.logRetry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9478) SQL: throw reducer retry error
[
https://issues.apache.org/jira/browse/IGNITE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9478:
Ignite Flags: (was: Docs Required)
> SQL: throw reducer retry error
> --
>
> Key: IGNITE-9478
> URL: https://issues.apache.org/jira/browse/IGNITE-9478
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
>
> Currently we cannot pass correct error message from reducer retry condition
> to user exception. Need to fix that. See
> \{{GridReduceQueryExecutor.logRetry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6195) SQL: Do not allow JOINs on caches with different affinity functions
[
https://issues.apache.org/jira/browse/IGNITE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6195:
Fix Version/s: (was: 2.7)
2.8
> SQL: Do not allow JOINs on caches with different affinity functions
> ---
>
> Key: IGNITE-6195
> URL: https://issues.apache.org/jira/browse/IGNITE-6195
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability, usability
> Fix For: 2.8
>
> Attachments: patch6195.patch
>
>
> Currently it is possible to execute JOIN on non-colocated caches. No
> exceptions will appear, user just receive incorrect result. We need to detect
> such situations and throw errors instead.
> *Proposed solution*
> Correct SQL result is possible when either distributed joins are enabled, or
> data is co-located properly. Under *proper* co-location we mean:
> 1) Participating {{PARTITIONED}} caches use the same affinity function
> 2) This affinity function doesn't depend on it's own previous state, i.e. it
> doesn't rely on {{AffinityFunctionContext.previousAssignment}}. For instance,
> {{RendezvousAffinityFunction}} doesn't use, while {{FairAffinityFunction}}
> does.
> As such, the following procedure should be implemented in order to determine
> whether SQL can be executed:
> 1) If {{distributedJoins}} are enabled - return, SQL can be executed
> 2) Get the list of participating caches
> 3) Exclude {{REPLICATED}} caches from that list
> 4) If all remaining caches belong to the same cache group - return, SQL can
> be executed
> 5) Get affinity function of the first cache
> 6) Check if affinity function doesn't use
> {{AffinityFunctionContext.previousAssignment}}. This could be controlled
> either through annotation, or through new method on {{AffinityFunction}}
> interface, e.g. {{boolean isDependOnPreviousState}}. If {{false}} - throw an
> exception
> 7) Check if affinity functions of all caches are equal through standard
> {{equals()}} method. If {{false}} - throw an exception.
> 8) Otherwise - SQL can be executed safely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9272) PureJavaCrc32 vs j.u.zip.CRC32 benchmark and probably replace.
[ https://issues.apache.org/jira/browse/IGNITE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631338#comment-16631338 ] Nikolay Izhikov commented on IGNITE-9272: - Hello [~zstan] I have done the review. Please, take a look at my comments in PR > PureJavaCrc32 vs j.u.zip.CRC32 benchmark and probably replace. > -- > > Key: IGNITE-9272 > URL: https://issues.apache.org/jira/browse/IGNITE-9272 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > Attachments: BenchmarkCRC.java > > > I see that Ignite has its own crc32 realization called: PureJavaCrc32 and > from desc it seems to be : _The current version is ~10x to 1.8x as fast as > Sun's native java.util.zip.CRC32 in Java 1.6_ But my jmh tests show opposite > results. > + If it really so, looks like backward compatibility would be easy, all that > need is just to take lower part of long form zip.crc32 realization. > jmh results: > Benchmark Mode CntScoreError Units > BenchmarkCRC.Crc32 avgt5 1521060.716 ± 44083.424 ns/op > BenchmarkCRC.pureJavaCrc32 avgt5 4657756.671 ± 177243.254 ns/op > JMH version: 1.21 > VM version: JDK 1.8.0_131, Java HotSpot(TM) 64-Bit Server VM, 25.131-b11 > VM invoker: /usr/lib/jvm/java-8-oracle/jre/bin/java > op system : ubuntu 16.10 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9733) Web Console: Add support for "type=number" on InputDialog
[ https://issues.apache.org/jira/browse/IGNITE-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631303#comment-16631303 ] Alexander Kalinin commented on IGNITE-9733: --- [~kuaw26] Added support and validations to type=number in input diaog, Please check. > Web Console: Add support for "type=number" on InputDialog > - > > Key: IGNITE-9733 > URL: https://issues.apache.org/jira/browse/IGNITE-9733 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.8 > > > Current implementation supports only text, lets add support for number. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9733) Web Console: Add support for "type=number" on InputDialog
[ https://issues.apache.org/jira/browse/IGNITE-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9733: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Web Console: Add support for "type=number" on InputDialog > - > > Key: IGNITE-9733 > URL: https://issues.apache.org/jira/browse/IGNITE-9733 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Current implementation supports only text, lets add support for number. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9733) Web Console: Add support for "type=number" on InputDialog
Alexey Kuznetsov created IGNITE-9733: Summary: Web Console: Add support for "type=number" on InputDialog Key: IGNITE-9733 URL: https://issues.apache.org/jira/browse/IGNITE-9733 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexander Kalinin Fix For: 2.8 Current implementation supports only text, lets add support for number. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9683) Create manual pinger for ZK client
[
https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631199#comment-16631199
]
Ignite TC Bot commented on IGNITE-9683:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 8 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=1953884]]
* exe: ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress -
2,0% fails in last 100 master runs.
* exe: ExecutableTest.TestInvalidCmdArgs - 2,0% fails in last 100 master runs.
* exe: CacheTest.TestGetMultithreadedSingleClient - 1,0% fails in last 100
master runs.
* exe: CacheTest.TestPutGetAsyncMultithreaded - 1,0% fails in last 100 master
runs.
* exe: CacheTest.TestGetMultithreadedSingleClient - 1,0% fails in last 100
master runs.
* exe: CacheTest.TestPutGetAsyncMultithreaded - 1,0% fails in last 100 master
runs.
* exe: CacheTest.TestGetMultithreadedSingleClient - 1,0% fails in last 100
master runs.
* exe: CacheTest.TestPutGetAsyncMultithreaded - 1,0% fails in last 100 master
runs.
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1954936]]
* IgniteHadoopFileSystemClientBasedPrimarySelfTest.testClientReconnect (last
started)
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests 0 Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=1952920]]
* GridOrderedMessageCancelSelfTest.testTaskException (last started)
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1953885]]
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1956621]]
{color:#d04437}SPI{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1954942]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinErrorMissedAddFinishedMessage2
- 1,0% fails in last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1954976]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
IgniteCacheP2pUnmarshallingErrorTest.testResponseMessageOnUnmarshallingFailed -
1,0% fails in last 100 master runs.
{color:#d04437}Platform C++ (Windows x64){color} [[tests
443|https://ci.ignite.apache.org/viewLog.html?buildId=1953879]]
* IgniteOdbcTest: QueriesTestSuite: TestManyCursors2 - 2,4% fails in last 100
master runs.
* IgniteCoreTest: BinaryIdentityResolverTestSuite: IdentityEquilityWithGuid -
2,0% fails in last 100 master runs.
* IgniteCoreTest: BinaryIdentityResolverTestSuite: IdentityEquilityWithoutGuid
- 2,0% fails in last 100 master runs.
* IgniteCoreTest: BinaryObjectTestSuite: RemoteSchemaRetrieval - 2,0% fails in
last 100 master runs.
* IgniteCoreTest: CacheInvokeTestSuite: TestExisting - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheInvokeTestSuite: TestNonExisting - 2,0% fails in last
100 master runs.
* IgniteCoreTest: CacheInvokeTestSuite: TestSeveral - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheInvokeTestSuite: TestStrings - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheStoreTestSuite: LoadCacheSeveralNodesNoPredicate - 2,0%
fails in last 100 master runs.
* IgniteCoreTest: CacheStoreTestSuite: LoadCacheSingleNodeNoPredicate - 2,0%
fails in last 100 master runs.
* IgniteCoreTest: CacheStoreTestSuite: LocalLoadCacheSingleNodeNoPredicate -
2,0% fails in last 100 master runs.
* IgniteCoreTest: CacheTestSuite: TestBinary - 2,0% fails in last 100 master
runs.
* IgniteCoreTest: CacheTestSuite: TestClear - 2,0% fails in last 100 master
runs.
* IgniteCoreTest: CacheTestSuite: TestContainsKey - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestContainsKeys - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestContainsKeysIter - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestCreateCache - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestGet - 2,0% fails in last 100 master runs.
* IgniteCoreTest: CacheTestSuite: TestGetAll - 2,0% fails in last 100 master
runs.
* IgniteCoreTest: CacheTestSuite: TestGetAllIterArray - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestGetAllIterMap - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestGetAndPut - 2,0% fails in last 100 master
runs.
* IgniteCoreTest: CacheTestSuite: TestGetAndPutIfAbsent - 2,0% fails in last
100 master runs.
* IgniteCoreTest: CacheTestSuite: TestGetAndRemove - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestGetAndReplace - 2,0% fails in last 100
master runs.
* IgniteCoreTest: CacheTestSuite: TestGetBigString - 2,0% fails in last 100
master runs.
* IgniteCoreTest:
[jira] [Commented] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16631132#comment-16631132 ] Ivan Daschinskiy commented on IGNITE-9693: -- I've found a small bug, related to test above, fixed and retriggered build again. > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > Attachments: successfull_local_test.PNG > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created
[ https://issues.apache.org/jira/browse/IGNITE-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9113: Fix Version/s: (was: 2.7) 2.8 > Allocate memory for a data region when first cache assigned to this region is > created > - > > Key: IGNITE-9113 > URL: https://issues.apache.org/jira/browse/IGNITE-9113 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.6 >Reporter: Valentin Kulichenko >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.8 > > > Currently we do not create any regions or allocate any offheap memory on > client nodes unless it's explicitly configured. This is good behavior, > however there is a usability issue caused by the fact that many users have > the same config file for both server and clients. This can lead to unexpected > excessive memory usage on client side and forces users to maintain two config > files in most cases. > Same issue is applied to server nodes that do not store any data (e.g. nodes > running only services). > It's better to allocate memory dynamically, when first cache assigned to a > data region is created. > More detailed discussion here: > http://apache-ignite-developers.2346864.n4.nabble.com/Data-regions-on-client-nodes-td32834.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9732) Add joins to Spark Dataframe examples
Valentin Kulichenko created IGNITE-9732:
---
Summary: Add joins to Spark Dataframe examples
Key: IGNITE-9732
URL: https://issues.apache.org/jira/browse/IGNITE-9732
Project: Ignite
Issue Type: Improvement
Components: examples, spark
Affects Versions: 2.6
Reporter: Valentin Kulichenko
Fix For: 2.7
{{IgniteDataFrameExample}} creates two tables - {{city}} and {{person}}, but
only {{person}} is actually used. Need to add join examples.
Would also be great to demonstrate the fact that optimization is working and
joins are executed in Ignite, not Spark (using {{explain()}}, maybe?).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9683) Create manual pinger for ZK client
[
https://issues.apache.org/jira/browse/IGNITE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630952#comment-16630952
]
Ignite TC Bot commented on IGNITE-9683:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1949100buildTypeId=IgniteTests24Java8_RunAll]
> Create manual pinger for ZK client
> --
>
> Key: IGNITE-9683
> URL: https://issues.apache.org/jira/browse/IGNITE-9683
> Project: Ignite
> Issue Type: Improvement
> Components: cache, zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Andrew Medvedev
>Priority: Major
> Fix For: 2.7
>
>
> Connection loss with Zookeeper more than ZK session timeout for server nodes
> is unacceptable. To improve durability of connrction, we need to keep session
> with ZK as long possible. We need to introduce manual pinger additionally to
> ZK client and ping ZK server with simple request each tick time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9501) Exclude newly joining nodes from exchange latch
[ https://issues.apache.org/jira/browse/IGNITE-9501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630894#comment-16630894 ] ASF GitHub Bot commented on IGNITE-9501: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/4860 IGNITE-9501 Backward compatibility fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9501-compatibility-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4860.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 #4860 commit 88c38d0c000154735c1e1aa7c092ddb37dbf0c90 Author: Pavel Kovalenko Date: 2018-09-27T18:50:31Z IGNITE-9501 Backward compatibility fix. > Exclude newly joining nodes from exchange latch > > > Key: IGNITE-9501 > URL: https://issues.apache.org/jira/browse/IGNITE-9501 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently, we're waiting for latch completion from newly joining nodes. > However, such nodes don't have any updates to be synced on wait partitions > release. Newly joining nodes may start their caches before exchange latch > creation and this can delay exchange process. > We should explicitly ignore such nodes and don't include them into latch > participants. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9731) NPE is possible during WAL flushing
[
https://issues.apache.org/jira/browse/IGNITE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-9731:
-
Issue Type: Bug (was: Task)
> NPE is possible during WAL flushing
> ---
>
> Key: IGNITE-9731
> URL: https://issues.apache.org/jira/browse/IGNITE-9731
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Kuznetsov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: WalRolloverRecordLoggingTest.java
>
>
> {{FileWriteAheadLogManager.flush()}} seems to be not thread-safe anymore in
> master branch. The test attached produces the following NPE:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileHandle.getSegmentId(FileWriteAheadLogManager.java:2371)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.needFsync(FileWriteAheadLogManager.java:2642)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2668)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1900(FileWriteAheadLogManager.java:2445)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:866)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3633)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3126)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3025)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could be possibly brought by commit [1].
> [1]
> https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9731) NPE is possible during WAL flushing
Andrey Kuznetsov created IGNITE-9731:
Summary: NPE is possible during WAL flushing
Key: IGNITE-9731
URL: https://issues.apache.org/jira/browse/IGNITE-9731
Project: Ignite
Issue Type: Task
Reporter: Andrey Kuznetsov
Fix For: 2.7
Attachments: WalRolloverRecordLoggingTest.java
{{FileWriteAheadLogManager.flush()}} seems to be not thread-safe anymore in
master branch. The test attached produces the following NPE:
{noformat}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileHandle.getSegmentId(FileWriteAheadLogManager.java:2371)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.needFsync(FileWriteAheadLogManager.java:2642)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2668)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1900(FileWriteAheadLogManager.java:2445)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:866)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3633)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3126)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3025)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
This could be possibly brought by commit [1].
[1]
https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7282) .NET: Thin client: Failover
[ https://issues.apache.org/jira/browse/IGNITE-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630726#comment-16630726 ] ASF GitHub Bot commented on IGNITE-7282: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3467 > .NET: Thin client: Failover > --- > > Key: IGNITE-7282 > URL: https://issues.apache.org/jira/browse/IGNITE-7282 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.7 > > > Currently user has to manually connect to some specific Ignite server. > Implement some kind of automatic failover where Thin Client knows about > multiple nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-9693: - Attachment: successfull_local_test.PNG > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > Attachments: successfull_local_test.PNG > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630725#comment-16630725 ] Ivan Daschinskiy commented on IGNITE-9693: -- WalCompactionTest#testCompressorToleratesEmptyWalSegments seems to be flaky on final assertion. Locally ran multiple times -- no failures !successfull_local_test.PNG! > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > Attachments: successfull_local_test.PNG > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9612) Improve checkpoint mark phase speed.
[
https://issues.apache.org/jira/browse/IGNITE-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630721#comment-16630721
]
Alexei Scherbakov commented on IGNITE-9612:
---
The ticket requires fix for concurrency issue with PartitionAllocationMap - it
uses thread-unsafe collections
Fixed with commit [1]
[1] 4527fe6de8bddea31a8142e78a84eacb534d0384
> Improve checkpoint mark phase speed.
>
>
> Key: IGNITE-9612
> URL: https://issues.apache.org/jira/browse/IGNITE-9612
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
>
> I'm observing regular slow checkpoints due to long mark duration, which is
> not related to dirty pages number:
> {noformat}
> 2018-09-01 14:55:20.408 [INFO
> ][db-checkpoint-thread-#241%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=01e0c7bf-842f-4ed6-8589-b4904063434f,
> startPtr=FileWALPointer [idx=19814, fileOff=948996096, len=5233457],
> checkpointLockWait=0ms, checkpointLockHoldTime=951ms,
> walCpRecordFsyncDuration=39ms, pages=78477, reason='timeout']
> 2018-09-01 14:55:21.307 [INFO
> ][db-checkpoint-thread-#241%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=01e0c7bf-842f-4ed6-8589-b4904063434f, pages=78477,
> markPos=FileWALPointer [idx=19814, fileOff=948996096, len=5233457],
> walSegmentsCleared=0, walSegmentsCovered=[], *markDuration=1002m*s,
> pagesWrite=478ms, fsync=421ms, total=1901ms]
> {noformat}
> {noformat}
> 2018-09-01 14:58:20.355 [INFO
> ][db-checkpoint-thread-#241%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=09d1f4bc-d3f3-4a16-b291-89d7fa745ea5,
> startPtr=FileWALPointer [idx=19814, fileOff=124208, len=5233457],
> checkpointLockWait=0ms, checkpointLockHoldTime=926ms,
> walCpRecordFsyncDuration=14ms, pages=10837, reason='timeout']
> 2018-09-01 14:58:20.480 [INFO
> ][db-checkpoint-thread-#241%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=09d1f4bc-d3f3-4a16-b291-89d7fa745ea5, pages=10837,
> markPos=FileWALPointer [idx=19814, fileOff=124208, len=5233457],
> walSegmentsCleared=0, walSegmentsCovered=[], *markDuration=943ms*,
> pagesWrite=64ms, fsync=61ms, total=1068ms]
> {noformat}
> Debugging has revealed what this is due to large amount of work required to
> save metadata for metapages and free/reuse lists. Because this is done under
> checkpoint write lock, all other activities are blocked, resulting in
> increased tx and atomic ops latency.
> Simple solution: parallelize metadata processing during mark phase.
> Best way to solve the problem is described in IGNITE-9520.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7282) .NET: Thin client: Failover
[
https://issues.apache.org/jira/browse/IGNITE-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630722#comment-16630722
]
Pavel Tupitsyn commented on IGNITE-7282:
Merged to master: {{45abb9c7069291d1bafa4a26edf23a36cc527716}}.
Cherry-picked to ignite-2.7: {{2279e687997160525ae688b87f6d402660040359}}
> .NET: Thin client: Failover
> ---
>
> Key: IGNITE-7282
> URL: https://issues.apache.org/jira/browse/IGNITE-7282
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.7
>
>
> Currently user has to manually connect to some specific Ignite server.
> Implement some kind of automatic failover where Thin Client knows about
> multiple nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630687#comment-16630687 ] Denis Magda commented on IGNITE-7595: - [~Artem Budnikov], [~pgarg], please start looking into this take. We'd like to hear your opinion on the new structure. > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.8 > > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9582) Document Model Updating
[ https://issues.apache.org/jira/browse/IGNITE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9582: Comment: was deleted (was: [https://docs.google.com/document/d/1xJMenCjYNV8EgqosPzcRDC9g1sZ9xIKEKopSnLAdBz0/edit?usp=sharing]) > Document Model Updating > --- > > Key: IGNITE-9582 > URL: https://issues.apache.org/jira/browse/IGNITE-9582 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > The documentation for the new page with name "Model Updating / Online > Learning" > [https://docs.google.com/document/d/113WZTNdge0Ubom8RndnpOsPZ7yetYT9jZx16Fp_uJhE/edit?usp=sharing] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9579) Document Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9579: Comment: was deleted (was: [https://docs.google.com/document/d/1ZLdZrQvIl2d_oMJIoc0fKMAmr1PKSv-r-vAmQdXY4ao/edit?usp=sharing]) > Document Random Forest > -- > > Key: IGNITE-9579 > URL: https://issues.apache.org/jira/browse/IGNITE-9579 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > The link for new page with name "Random Forest" is here > https://docs.google.com/document/d/14t67HlWBaoV91887NjqbrsT0dAuExIxUOxYiaIbwEt4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9574) Document Gradient boosting
[ https://issues.apache.org/jira/browse/IGNITE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9574: Comment: was deleted (was: [https://docs.google.com/document/d/1kLbJOIup5B918Ku86lig5DacyUWLfSp7iF5U1Uv7WOw/edit?usp=sharing]) > Document Gradient boosting > -- > > Key: IGNITE-9574 > URL: https://issues.apache.org/jira/browse/IGNITE-9574 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > The documentation for the new page with name "Gradient Boosting" > https://docs.google.com/document/d/1Twztetmpu9hH9ueomhAOUZSLUCukk8AvY9ibuicDCXI/edit -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630645#comment-16630645 ] Uday Kale commented on IGNITE-9532: --- [~avinogradov] Oh ok. I have updated the PR with first two changes only. > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9549) control.sh add command to collect information on the distribution of partitions and reset lost partitions
[
https://issues.apache.org/jira/browse/IGNITE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630642#comment-16630642
]
ASF GitHub Bot commented on IGNITE-9549:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4734
> control.sh add command to collect information on the distribution of
> partitions and reset lost partitions
> -
>
> Key: IGNITE-9549
> URL: https://issues.apache.org/jira/browse/IGNITE-9549
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexand Polyakov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.7
>
> Attachments: Possible blockers.png,
> org.apache.ignite.internal.processors.cache.query.CacheScanQueryFailoverTest#testScanQueryWithFailedClosures.png,
>
> org.apache.ignite.internal.processors.query.h2.GridIndexRebuildWithMvccEnabledSelfTest#testIndexRebuild.png,
> screenshot-1.png
>
>
> control.sh add command to collect information on the distribution of
> partitions
> {noformat}
> control.sh --cache distribution nodeId|null [cacheName1[,...,cacheNameN]]
> [--user-attributes userAttribute[,...,userAttributeN]]
> {noformat}
> return
> [next group: id=??, name=??]
> groupId,partition,nodeId,primary,state,updateCounter,size,nodeAddresses[,userAttribute[,...,userAttributeN]]
> ...
> groupId,partition,nodeId,primary,state,updateCounter,size,nodeAddresses[,userAttribute[,...,userAttributeN]]
> reset lost partitions
> {noformat}
> control.sh --cache reset_lost_partitions cacheName1[,...,cacheNameN]
> {noformat}
> return
> Reset LOST-partitions performed successfully. Cache group (name = '??', id =
> ??)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9684) JDK9: pass JVM options to created process at HadoopCommandLineTest#createProcessBuilder
[
https://issues.apache.org/jira/browse/IGNITE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9684:
-
Fix Version/s: 2.7
> JDK9: pass JVM options to created process at
> HadoopCommandLineTest#createProcessBuilder
> ---
>
> Key: IGNITE-9684
> URL: https://issues.apache.org/jira/browse/IGNITE-9684
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> To support JDK9 the JVM options must be passed to created process:
> see {{HadoopCommandLineTest#createProcessBuilder}}
> Because lauched process fails with
> {code}
> IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe
> cannot access class jdk.internal.misc.SharedSecrets (in module java.base)
> because module java.base does not export jdk.internal.misc to unnamed module
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9687) JDK9: JTA tests failed
[
https://issues.apache.org/jira/browse/IGNITE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9687:
-
Fix Version/s: 2.7
> JDK9: JTA tests failed
> --
>
> Key: IGNITE-9687
> URL: https://issues.apache.org/jira/browse/IGNITE-9687
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> JTA tests fail on JDK9 with error:
> {{java.lang.NoClassDefFoundError: javax/rmi/PortableRemoteObject}}
> the option {{--add-modules java.se.ee}}
> changes the error to:
> {{java.lang.NoClassDefFoundError: javax/transaction/UserTransaction}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9727) JDK9/10/11: ignite run script must be works with JDK9/10/11
[
https://issues.apache.org/jira/browse/IGNITE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9727:
-
Fix Version/s: 2.7
> JDK9/10/11: ignite run script must be works with JDK9/10/11
> ---
>
> Key: IGNITE-9727
> URL: https://issues.apache.org/jira/browse/IGNITE-9727
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> {{ignite.sh/bat}} and other scripts must be works properly with JDK 9/10/11
> versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9728) JDK11: external class loader problem
[
https://issues.apache.org/jira/browse/IGNITE-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9728:
Fix Version/s: 2.7
> JDK11: external class loader problem
>
>
> Key: IGNITE-9728
> URL: https://issues.apache.org/jira/browse/IGNITE-9728
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> A lot of tests fail with {{ClassNotFoundException}} because external class
> loader set up incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630624#comment-16630624 ] Anton Vinogradov commented on IGNITE-9532: -- [~uday] Just wanted to ask to find a way to solve duplication properly. To minimize changes. > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9730) JdbcThinDatabaseMetadata.getTables() is case-sensitive
Pat Patterson created IGNITE-9730:
-
Summary: JdbcThinDatabaseMetadata.getTables() is case-sensitive
Key: IGNITE-9730
URL: https://issues.apache.org/jira/browse/IGNITE-9730
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Pat Patterson
Create a table {{Tester}}, try to get its metadata via
{{JdbcThinDatabaseMetadata.getTables()}}. No metadata is returned unless you
use an uppercase table name.
Issue seems to be that {{matches()}} in {{JdbcRequestHandler}} is case
sensitive, unlike {{matches()}} in the client driver at
{{JdbcDatabaseMetadata}}.
Easily reproducible:
{noformat}
public static void testGetTables() throws ClassNotFoundException, SQLException {
// Register JDBC driver.
Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
// Open JDBC connection.
try (Connection conn =
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
String tableName = "Tester";
// Create database table
try (Statement stmt = conn.createStatement()) {
stmt.executeUpdate("CREATE TABLE " + tableName + " (" +
" ID LONG PRIMARY KEY, NAME VARCHAR) " +
" WITH \"template=replicated\"");
}
// Get database metadata
DatabaseMetaData md = conn.getMetaData();
// Get table metadata
ResultSet rs = md.getTables(conn.getCatalog(), "", tableName, new
String[]{"TABLE"});
System.out.println((rs.next() ? "Found metadata for " : "No metadata for
") + tableName);
// Try again with uppercase
tableName = tableName.toUpperCase();
rs = md.getTables(conn.getCatalog(), "", tableName, new
String[]{"TABLE"});
System.out.println((rs.next() ? "Found metadata for " : "No metadata for
") + tableName);
}
}
{noformat}
Expected output:
{noformat}
Found metadata for Tester
Found metadata for TESTER
{noformat}
Actual output:
{noformat}
No metadata for Tester
Found metadata for TESTER
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630620#comment-16630620 ] Ivan Daschinskiy commented on IGNITE-9693: -- [Latest|https://ci.ignite.apache.org/viewLog.html?buildId=1955602=buildResultsDiv=IgniteTests24Java8_RunAll] [~ivan.glukos] Hi. I've reimplemented logic, now use brand new SegmentAware. However, implementing the same logic for FsyncFileWALManager is not possible, because this logic is not inserted here. Is it ok to create another ticket for FsyncManager? Nevertheless, waiting for new TC runAll() > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9693) Scale up wal compression workers to increase performance
[ https://issues.apache.org/jira/browse/IGNITE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630620#comment-16630620 ] Ivan Daschinskiy edited comment on IGNITE-9693 at 9/27/18 3:33 PM: --- [Latest TC run|https://ci.ignite.apache.org/viewLog.html?buildId=1955602=buildResultsDiv=IgniteTests24Java8_RunAll] [~ivan.glukos] Hi. I've reimplemented logic, now use brand new SegmentAware. However, implementing the same logic for FsyncFileWALManager is not possible, because this logic is not inserted here. Is it ok to create another ticket for FsyncManager? Nevertheless, waiting for new TC runAll() was (Author: ivandasch): [Latest|https://ci.ignite.apache.org/viewLog.html?buildId=1955602=buildResultsDiv=IgniteTests24Java8_RunAll] [~ivan.glukos] Hi. I've reimplemented logic, now use brand new SegmentAware. However, implementing the same logic for FsyncFileWALManager is not possible, because this logic is not inserted here. Is it ok to create another ticket for FsyncManager? Nevertheless, waiting for new TC runAll() > Scale up wal compression workers to increase performance > > > Key: IGNITE-9693 > URL: https://issues.apache.org/jira/browse/IGNITE-9693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630614#comment-16630614
]
Uday Kale commented on IGNITE-9532:
---
[~avinogradov]
I will make the first to changes. For the third change, the duplication is
because the a binary cache will only support primitives, {{String}} and
{{BinaryObject}} types. This is mentioned in the comments of
{{IgniteCache#withKeepBinary()}}. The {{testCollectionMethods}} uses the
{{SameHashItem}} POJO which is not directly supported by the binary cache. That
is why I have created {{testCollectionMethodsBin}} which uses the binary cache
friendly object type.
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9729) Ability to start GridQueryProcessor in parallel
Anton Kalashnikov created IGNITE-9729: - Summary: Ability to start GridQueryProcessor in parallel Key: IGNITE-9729 URL: https://issues.apache.org/jira/browse/IGNITE-9729 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov After task [StartCachesInParallel|https://issues.apache.org/jira/browse/IGNITE-8006] we can start caches in parallel but GridQueryProcessor is narrow place because it should be start consistently by following reasons: * checking index to duplicate(and other checking) require one order on every nodes. * onCacheStart and createSchema contains a lot of mutex. * maybe it has other reasons. After this task GridCacheProcessor#prepareStartCaches should be rewrited. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9697) [TC Bot] Autocomplete branch for TC field
[
https://issues.apache.org/jira/browse/IGNITE-9697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630593#comment-16630593
]
ASF GitHub Bot commented on IGNITE-9697:
SomeFire closed pull request #22: IGNITE-9697 [TC Bot] Autocomplete branch for
TC field
URL: https://github.com/apache/ignite-teamcity-bot/pull/22
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/conf/ChainAtServer.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/conf/ChainAtServer.java
index fc61c75..325327f 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/conf/ChainAtServer.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/conf/ChainAtServer.java
@@ -32,6 +32,12 @@
/** Suite identifier by teamcity identification for root chain. */
@Nonnull public String suiteId;
+/** URL for git integration. */
+@Nullable public String gitApiUrl;
+
+/** URL for JIRA integration. */
+@Nullable public String jiraApiUrl;
+
public ChainAtServer() {
}
@@ -39,6 +45,8 @@ public ChainAtServer() {
public ChainAtServer(ChainAtServer o) {
this.serverId = o.serverId;
this.suiteId = o.suiteId;
+this.gitApiUrl = o.gitApiUrl;
+this.jiraApiUrl = o.jiraApiUrl;
}
/** {@inheritDoc} */
@@ -52,12 +60,14 @@ public ChainAtServer(ChainAtServer o) {
ChainAtServer srv = (ChainAtServer)o;
return Objects.equals(serverId, srv.serverId) &&
-Objects.equals(suiteId, srv.suiteId);
+Objects.equals(suiteId, srv.suiteId)&&
+Objects.equals(gitApiUrl, srv.gitApiUrl)&&
+Objects.equals(jiraApiUrl, srv.jiraApiUrl);
}
/** {@inheritDoc} */
@Override public int hashCode() {
-return Objects.hash(serverId, suiteId);
+return Objects.hash(serverId, suiteId, gitApiUrl, jiraApiUrl);
}
/**
diff --git a/ignite-tc-helper-web/src/main/webapp/index.html
b/ignite-tc-helper-web/src/main/webapp/index.html
index 1dc6eba..73cfb07 100644
--- a/ignite-tc-helper-web/src/main/webapp/index.html
+++ b/ignite-tc-helper-web/src/main/webapp/index.html
@@ -78,23 +78,29 @@
function showSuitesForPrCheckData(result) {
var res = "";
+
for (var i = 0; i < result.length; i++) {
var chainAtServer = result[i];
//res+="Check
PR";
+gitUrls.set(chainAtServer.serverId, chainAtServer.gitApiUrl);
+
res += "";
res += "Server: ";
res += "Chain: ";
res += "Base branch: ";
-res += "Branch: ";
+res += "Branch: ";
res += "";
// res+="";
res += "";
res += "";
}
+
$("#suitesForPrCheck").html(res);
-}
+sendRequestsToFillAutocompleteLists();
+}
function showBuildsOnServers(result) {
var res = "";
diff --git a/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
b/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
index 6ef59d0..7487c2f 100644
--- a/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
+++ b/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
@@ -202,3 +202,95 @@ function tcHelperLogout() {
} catch (e) {
}
}
+
+/**
+ * Change autocomplete filter to show results only when they starts from
written text.
+ */
+$.ui.autocomplete.filter = function (array, term) {
+var matcher = new RegExp("^" + $.ui.autocomplete.escapeRegex(term), "i");
+
+return $.grep(array, function (value) {
+return matcher.test(value.label || value.value || value);
+});
+};
+
+var callbackRegistry = {};
+
+/**
+ * Send request to another site.
+ *
+ * @param url URL.
+ * @param onSuccess Function for success response.
+ * @param onError Function for fail response.
+ */
+function scriptRequest(url, onSuccess, onError) {
+var scriptOk = false;
+
+var callbackName = 'cb' + String(Math.random()).slice(-6);
+
+url += ~url.indexOf('?') ? '&' : '?';
+url += 'callback=callbackRegistry.' + callbackName;
+
+callbackRegistry[callbackName] = function(data) {
+scriptOk = true;
+
+delete callbackRegistry[callbackName];
+
+onSuccess(data);
+};
+
+function checkCallback() {
+if (scriptOk)
+return;
+
+delete callbackRegistry[callbackName];
+
+onError(url);
+}
+
+var script = document.createElement('script');
+
+script.onload = script.onerror = checkCallback;
+script.src = url;
+
+document.body.appendChild(script);
+}
+
+/**
+ * Key - server id.
+ * Value - url to git api.
+ *
+ * @type {Map}
+ */
+var gitUrls = new Map();
+
+/**
+ * Send requests to the git to
[jira] [Created] (IGNITE-9728) JDK11: external class loader problem
Taras Ledkov created IGNITE-9728:
Summary: JDK11: external class loader problem
Key: IGNITE-9728
URL: https://issues.apache.org/jira/browse/IGNITE-9728
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
A lot of tests fail with {{ClassNotFoundException}} because external class
loader set up incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630584#comment-16630584 ] Dmitriy Pavlov commented on IGNITE-8617: [~uday], thanks, I retriggered failed suites for PR. > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.7 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8220) Discovery worker termination in PDS test
[
https://issues.apache.org/jira/browse/IGNITE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630581#comment-16630581
]
ASF GitHub Bot commented on IGNITE-8220:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4386
> Discovery worker termination in PDS test
>
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> 3 suites failed
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3
> {noformat}
> [2018-04-11
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
> is terminated unexpectedly.]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8220) Discovery worker termination in PDS test
[
https://issues.apache.org/jira/browse/IGNITE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630577#comment-16630577
]
Dmitriy Pavlov edited comment on IGNITE-8220 at 9/27/18 3:03 PM:
-
I've checked all possible blockers: It seems these tests were already fixed in
master. Some of them continued to have floating failures. So IMO it is not a
blocker.
Merged to master and cherry-picked to 2.7
[~EdShangGG] [~alex_pl] [~akalashnikov] thank you for contribution.
[~ibessonov] thank you for review.
was (Author: dpavlov):
I've checked all possible blockers: It seems these tests were already fixed in
master. Some of them continued to have floating failures. So IMO it is not a
blocker.
Merged to master and cherry-picked to 2.7
[~EdShangGG] [~alex_pl] thank you for contribution.
[~ibessonov] thank you for review.
> Discovery worker termination in PDS test
>
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> 3 suites failed
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3
> {noformat}
> [2018-04-11
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
> is terminated unexpectedly.]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630572#comment-16630572
]
Anton Vinogradov edited comment on IGNITE-9532 at 9/27/18 3:02 PM:
---
[~uday]
1) Can we avoid copy-paste at {{withKeepBinary}} javadoc?
Let's make it smaller and simpler :)
2) rollback changes not related to the issue.
I see formatting changes at {{testPutGetMultithreadUnbounded}} method and at
{{testIsolation}} javadoc.
3) I see code duplication between {{testCollectionMethods}} and
{{testCollectionMethodsBin}}.
was (Author: avinogradov):
[~uday]
1) Can we avoid copy-paste at {{withKeepBinary}} javadoc?
Let's make it smaller and simpler :)
2) rollback changes to related to the issue.
I see formatting changes at {{testPutGetMultithreadUnbounded}} method and at
{{testIsolation}} javadoc.
3) I see code duplication between {{testCollectionMethods}} and
{{testCollectionMethodsBin}}.
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630572#comment-16630572
]
Anton Vinogradov commented on IGNITE-9532:
--
[~uday]
1) Can we avoid copy-paste at {{withKeepBinary}} javadoc?
Let's make it smaller and simpler :)
2) rollback changes to related to the issue.
I see formatting changes at {{testPutGetMultithreadUnbounded}} method and at
{{testIsolation}} javadoc.
3) I see code duplication between {{testCollectionMethods}} and
{{testCollectionMethodsBin}}.
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9630) Partitions intersection for AND condition of same key
[ https://issues.apache.org/jira/browse/IGNITE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630565#comment-16630565 ] Sergey Grimstad commented on IGNITE-9630: - Branched from 9632 > Partitions intersection for AND condition of same key > - > > Key: IGNITE-9630 > URL: https://issues.apache.org/jira/browse/IGNITE-9630 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > GridSqlQuerySplitter when extractPartition for AND operation type should > calculate intersection of resolved partitions for the same key -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630561#comment-16630561 ] ASF GitHub Bot commented on IGNITE-9726: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4859 IGNITE-9726: GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9726 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4859.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 #4859 commit d02093c29d106b4ff4900ed7013d819880992e92 Author: Alexey Platonov Date: 2018-09-27T14:46:22Z fix suite lock due to missing of interruption in child threads commit 40c3206752e2615603a85e0dbe56c2c0bc3266be Author: Alexey Platonov Date: 2018-09-27T14:46:34Z Merge branch 'master' of https://github.com/apache/ignite into ignite-9726 > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630556#comment-16630556 ] Uday Kale commented on IGNITE-8617: --- [~dpavlov], Merged the master to the branch. > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.7 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption
[
https://issues.apache.org/jira/browse/IGNITE-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-6454:
---
Fix Version/s: (was: 2.7)
2.8
> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments:
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> - testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
> id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] : [Step 4/5] at
> java.lang.Exception.(Exception.java:66)
> [20:34:26] : [Step 4/5] at
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] : [Step 4/5] at
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] : [Step 4/5] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] : [Step 4/5] at
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] : [Step 4/5] at
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] : [Step 4/5]
> {noformat}
> That can be indicator that threads are interrupted and flag
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
> is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test
> and test continues to execute
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9727) JDK9/10/11: ignite run script must be works with JDK9/10/11
Taras Ledkov created IGNITE-9727:
Summary: JDK9/10/11: ignite run script must be works with
JDK9/10/11
Key: IGNITE-9727
URL: https://issues.apache.org/jira/browse/IGNITE-9727
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
{{ignite.sh/bat}} and other scripts must be works properly with JDK 9/10/11
versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7039) SQL: local query should pin affected partitions
[
https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630457#comment-16630457
]
Vladimir Ozerov edited comment on IGNITE-7039 at 9/27/18 2:41 PM:
--
This ticket appears to be related to IGNITE-6677, where we also parse
{{PreparedStatement}} in order to get the list of involved caches. In 6677 we
do that in more correct way - we use metadata of {{PreparedStatementEx}} in
order to re-use list of caches later.
For this reason it is better to wait for mentioned ticket to be resolved first,
and then re-use its cache ID calculation logic.
was (Author: vozerov):
This ticket appears to be related to IGNITE-6677, where we also parse
{{PreparedStatement}} in order to get the list of involved caches. However, in
this ticket we do that in more correct way - we use metadata of
{{PreparedStatementEx}} in order to re-use list of caches later.
For this reason it is better to wait for mentioned ticket to be resolved first,
and then re-use its cache ID calculation logic.
> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Attachments: 3194.patch
>
>
> When distributed query is executed, we pin cache partitions for particular
> topology version on map nodes [1]. However, it seems that we do no do that
> for local queries. This is a bug because partition with required data could
> be evicted from local node at any time, leading to incorrect results.
> [1]
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9687) JDK9: JTA tests failed
[
https://issues.apache.org/jira/browse/IGNITE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630536#comment-16630536
]
ASF GitHub Bot commented on IGNITE-9687:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/4858
IGNITE-9687: update dependencies
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9687
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4858.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 #4858
commit f6d2a93447ef4b93e23a39e12b29ecb2a2d651ce
Author: tledkov-gridgain
Date: 2018-09-27T13:39:06Z
IGNITE-9687: update dependencies
> JDK9: JTA tests failed
> --
>
> Key: IGNITE-9687
> URL: https://issues.apache.org/jira/browse/IGNITE-9687
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
>
> JTA tests fail on JDK9 with error:
> {{java.lang.NoClassDefFoundError: javax/rmi/PortableRemoteObject}}
> the option {{--add-modules java.se.ee}}
> changes the error to:
> {{java.lang.NoClassDefFoundError: javax/transaction/UserTransaction}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630537#comment-16630537 ] Dmitriy Pavlov commented on IGNITE-8617: [~uday], it seems a lot of failed tests were already fixed. Could you please merge current master into your branch? > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.7 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9687) JDK9: JTA tests failed
[
https://issues.apache.org/jira/browse/IGNITE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630535#comment-16630535
]
Taras Ledkov commented on IGNITE-9687:
--
The patch is not required.
To successful run add command line options (e.g. to MAVEN_OPTS):
{code}
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar
{code}
So, the full command line options to run Ignite testson JDK9:
{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-modules java.xml.bind \
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar"
{code}
> JDK9: JTA tests failed
> --
>
> Key: IGNITE-9687
> URL: https://issues.apache.org/jira/browse/IGNITE-9687
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
>
> JTA tests fail on JDK9 with error:
> {{java.lang.NoClassDefFoundError: javax/rmi/PortableRemoteObject}}
> the option {{--add-modules java.se.ee}}
> changes the error to:
> {{java.lang.NoClassDefFoundError: javax/transaction/UserTransaction}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9687) JDK9: JTA tests failed
[
https://issues.apache.org/jira/browse/IGNITE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630535#comment-16630535
]
Taras Ledkov edited comment on IGNITE-9687 at 9/27/18 2:38 PM:
---
The patch is not required.
To successful run add command line options (e.g. to MAVEN_OPTS):
{code}
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar
{code}
So, the full command line options to run Ignite tests on JDK9:
{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-modules java.xml.bind \
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar"
{code}
was (Author: tledkov-gridgain):
The patch is not required.
To successful run add command line options (e.g. to MAVEN_OPTS):
{code}
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar
{code}
So, the full command line options to run Ignite testson JDK9:
{code}
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-modules java.xml.bind \
--add-modules=java.corba \
--add-modules=java.transaction \
--illegal-access=permit \
--patch-module=java.transaction=$HOME/.m2/repository/javax/transaction/javax.transaction-api/1.3/javax.transaction-api-1.3.jar"
{code}
> JDK9: JTA tests failed
> --
>
> Key: IGNITE-9687
> URL: https://issues.apache.org/jira/browse/IGNITE-9687
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
>
> JTA tests fail on JDK9 with error:
> {{java.lang.NoClassDefFoundError: javax/rmi/PortableRemoteObject}}
> the option {{--add-modules java.se.ee}}
> changes the error to:
> {{java.lang.NoClassDefFoundError: javax/transaction/UserTransaction}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9716) Document partition distribution and reset lost partitions commands of control script
[ https://issues.apache.org/jira/browse/IGNITE-9716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630532#comment-16630532 ] Dmitriy Pavlov commented on IGNITE-9716: [~agoncharuk] please feel ticket description. How will a contributor know what needs to be documented? Will you communicate privately with contributor? > Document partition distribution and reset lost partitions commands of control > script > > > Key: IGNITE-9716 > URL: https://issues.apache.org/jira/browse/IGNITE-9716 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9716) Document partition distribution and reset lost partitions commands of control script
[ https://issues.apache.org/jira/browse/IGNITE-9716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630532#comment-16630532 ] Dmitriy Pavlov edited comment on IGNITE-9716 at 9/27/18 2:35 PM: - [~agoncharuk] please fill ticket description. How will a contributor know what needs to be documented? Will you communicate privately with contributor? was (Author: dpavlov): [~agoncharuk] please feel ticket description. How will a contributor know what needs to be documented? Will you communicate privately with contributor? > Document partition distribution and reset lost partitions commands of control > script > > > Key: IGNITE-9716 > URL: https://issues.apache.org/jira/browse/IGNITE-9716 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630526#comment-16630526 ] Dmitriy Pavlov commented on IGNITE-7196: I think we almost did this change, no reason to move it to 2.8. Am I missing something? > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], >
[jira] [Updated] (IGNITE-8386) SQL: Make sure PK index do not use wrapped object
[
https://issues.apache.org/jira/browse/IGNITE-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8386:
Fix Version/s: (was: 2.7)
2.8
> SQL: Make sure PK index do not use wrapped object
> -
>
> Key: IGNITE-8386
> URL: https://issues.apache.org/jira/browse/IGNITE-8386
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-19, performance
> Fix For: 2.8
>
>
> Currently PK may be built over the whole {{_KEY}} column, i.e. the whole
> binary object. This could happen in two cases:
> 1) Composite PK
> 2) Plain PK but with {{WRAP_KEY}} option.
> This is critical performance issue for two reasons:
> 1) This index is effectively useless and cannot be used in any sensible
> queries; it just wastes space and makes updates slower
> 2) Binary object typically has common header bytes what may lead to excessive
> number of comparisons during index update.
> To mitigate the problem we need to ensure that index is *never* built over
> {{_KEY}}, Instead, we must always extract target columns and build normal
> index over them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8386) SQL: Make sure PK index do not use wrapped object
[
https://issues.apache.org/jira/browse/IGNITE-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630528#comment-16630528
]
Vladimir Ozerov commented on IGNITE-8386:
-
Moving to AI 2.8 to minimize risks to AI 2.7 stabilization.
> SQL: Make sure PK index do not use wrapped object
> -
>
> Key: IGNITE-8386
> URL: https://issues.apache.org/jira/browse/IGNITE-8386
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-19, performance
> Fix For: 2.8
>
>
> Currently PK may be built over the whole {{_KEY}} column, i.e. the whole
> binary object. This could happen in two cases:
> 1) Composite PK
> 2) Plain PK but with {{WRAP_KEY}} option.
> This is critical performance issue for two reasons:
> 1) This index is effectively useless and cannot be used in any sensible
> queries; it just wastes space and makes updates slower
> 2) Binary object typically has common header bytes what may lead to excessive
> number of comparisons during index update.
> To mitigate the problem we need to ensure that index is *never* built over
> {{_KEY}}, Instead, we must always extract target columns and build normal
> index over them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7196: --- Fix Version/s: (was: 2.8) 2.7 > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, >
[jira] [Commented] (IGNITE-9632) Add support of trivial IN-operation for partition extraction
[ https://issues.apache.org/jira/browse/IGNITE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630523#comment-16630523 ] Sergey Grimstad commented on IGNITE-9632: - Build #4857 > Add support of trivial IN-operation for partition extraction > > > Key: IGNITE-9632 > URL: https://issues.apache.org/jira/browse/IGNITE-9632 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > Attachments: sgrimstad_IGNITE_9632_implementation_.patch > > > GridSqlQuerySplitter when extractPartition should support IN operations for > simple cases like IN (const, const ...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9632) Add support of trivial IN-operation for partition extraction
[ https://issues.apache.org/jira/browse/IGNITE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630521#comment-16630521 ] ASF GitHub Bot commented on IGNITE-9632: GitHub user SGrimstad opened a pull request: https://github.com/apache/ignite/pull/4857 IGNITE-9632 implementation You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9632 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4857.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 #4857 commit 1a41a15edf6ad9f394fc09fc91052abbf7004d7f Author: SGrimstad Date: 2018-09-27T14:23:28Z IGNITE-9632 implementation > Add support of trivial IN-operation for partition extraction > > > Key: IGNITE-9632 > URL: https://issues.apache.org/jira/browse/IGNITE-9632 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > GridSqlQuerySplitter when extractPartition should support IN operations for > simple cases like IN (const, const ...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9726: Description: Example of timeouts: [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] method testConstantTopologyChange can misses interrupt from test runner and lock suite see that after thread dump put/remove cache operations will continue > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9726: Description: Example of timeouts: [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] method testConstantTopologyChange can misses interrupt from test runner and lock suite see that after thread dump put/remove cache operations will continue in test testOptimisticSerializableTxConstantTopologyChange was: Example of timeouts: [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] method testConstantTopologyChange can misses interrupt from test runner and lock suite see that after thread dump put/remove cache operations will continue > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646=IgniteTests24Java8_CacheFailover2=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630509#comment-16630509 ] ASF GitHub Bot commented on IGNITE-9550: GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/4856 IGNITE-9550 ready future exchange actions You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9550-dg-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4856.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 #4856 commit 1e9e673dd3cde9c9a2d069965681f61d137847d6 Author: Dmitriy Govorukhin Date: 2018-09-27T14:20:20Z IGNITE-9550 ready future exchange actions > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.7 > > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
Alexey Platonov created IGNITE-9726: --- Summary: GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations Key: IGNITE-9726 URL: https://issues.apache.org/jira/browse/IGNITE-9726 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov Assignee: Alexey Platonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630496#comment-16630496
]
ASF GitHub Bot commented on IGNITE-9654:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4797
> Test testJoinQueryUnstableTopology is flaky in master
> -
>
> Key: IGNITE-9654
> URL: https://issues.apache.org/jira/browse/IGNITE-9654
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
> Log:
> {noformat}
> Failed to stop grid
> [igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
> cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7699)
> ... 9 more
> java.lang.RuntimeException: Not all Ignite instances has been stopped.
> Please, see log for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9725) Introduce affinity distribution prototype for similar cache group configurations
[ https://issues.apache.org/jira/browse/IGNITE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9725: Labels: cache performance (was: ) > Introduce affinity distribution prototype for similar cache group > configurations > > > Key: IGNITE-9725 > URL: https://issues.apache.org/jira/browse/IGNITE-9725 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Pavel Kovalenko >Priority: Major > Labels: cache, performance > Fix For: 2.8 > > > Currently, we perform affinity re-calculation for each of cache groups, even > if configurations (CacheMode, number of backups, affinity function) are equal. > > If two cache groups have similar affinity function and number of backups we > can calculate affinity prototype for such groups once and re-use in every > cache group. > This change will save time on affinity re-calculation if a cluster has a lot > of cache groups with similar affinity function. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9725) Introduce affinity distribution prototype for similiar cache group configurations
[ https://issues.apache.org/jira/browse/IGNITE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9725: Summary: Introduce affinity distribution prototype for similiar cache group configurations (was: Introduce affinity distribution prototype for equal cache group configurations) > Introduce affinity distribution prototype for similiar cache group > configurations > - > > Key: IGNITE-9725 > URL: https://issues.apache.org/jira/browse/IGNITE-9725 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.8 > > > Currently, we perform affinity re-calculation for each of cache groups, even > if configurations (CacheMode, number of backups, affinity function) are equal. > > If two cache groups have similar affinity function and number of backups we > can calculate affinity prototype for such groups once and re-use in every > cache group. > This change will save time on affinity re-calculation if a cluster has a lot > of cache groups with similar affinity function. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9725) Introduce affinity distribution prototype for equal cache group configurations
Pavel Kovalenko created IGNITE-9725: --- Summary: Introduce affinity distribution prototype for equal cache group configurations Key: IGNITE-9725 URL: https://issues.apache.org/jira/browse/IGNITE-9725 Project: Ignite Issue Type: New Feature Components: cache Affects Versions: 2.0 Reporter: Pavel Kovalenko Fix For: 2.8 Currently, we perform affinity re-calculation for each of cache groups, even if configurations (CacheMode, number of backups, affinity function) are equal. If two cache groups have similar affinity function and number of backups we can calculate affinity prototype for such groups once and re-use in every cache group. This change will save time on affinity re-calculation if a cluster has a lot of cache groups with similar affinity function. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9725) Introduce affinity distribution prototype for similar cache group configurations
[ https://issues.apache.org/jira/browse/IGNITE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9725: Summary: Introduce affinity distribution prototype for similar cache group configurations (was: Introduce affinity distribution prototype for similiar cache group configurations) > Introduce affinity distribution prototype for similar cache group > configurations > > > Key: IGNITE-9725 > URL: https://issues.apache.org/jira/browse/IGNITE-9725 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.8 > > > Currently, we perform affinity re-calculation for each of cache groups, even > if configurations (CacheMode, number of backups, affinity function) are equal. > > If two cache groups have similar affinity function and number of backups we > can calculate affinity prototype for such groups once and re-use in every > cache group. > This change will save time on affinity re-calculation if a cluster has a lot > of cache groups with similar affinity function. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630488#comment-16630488
]
Alexey Goncharuk edited comment on IGNITE-9654 at 9/27/18 2:10 PM:
---
Thanks, [~NSAmelchev], merged to master and ignite-2.7.
was (Author: agoncharuk):
Thanks, [~NSAmelchev], merged to master.
> Test testJoinQueryUnstableTopology is flaky in master
> -
>
> Key: IGNITE-9654
> URL: https://issues.apache.org/jira/browse/IGNITE-9654
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
> Log:
> {noformat}
> Failed to stop grid
> [igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
> cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7699)
> ... 9 more
> java.lang.RuntimeException: Not all Ignite instances has been stopped.
> Please, see log for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9654) Test testJoinQueryUnstableTopology is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9654:
-
Fix Version/s: (was: 2.8)
2.7
> Test testJoinQueryUnstableTopology is flaky in master
> -
>
> Key: IGNITE-9654
> URL: https://issues.apache.org/jira/browse/IGNITE-9654
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test
> IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
> is flaky in master. [Example of
> fail|https://ci.ignite.apache.org/viewLog.html?buildId=1910548=buildResultsDiv=IgniteTests24Java8_Queries1#testNameId-9054712716754027821].
> Log:
> {noformat}
> Failed to stop grid
> [igniteInstanceName=near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest5,
> cancel=false]
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7704)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1672)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2293)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1155)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1130)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1430)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.access$100(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:35)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:96)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest$2.call(IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.java:79)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7699)
> ... 9 more
> java.lang.RuntimeException: Not all Ignite instances has been stopped.
> Please, see log for details.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630468#comment-16630468
]
ASF GitHub Bot commented on IGNITE-9686:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4855
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7039: Fix Version/s: (was: 2.7) 2.8 > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Sergey Grimstad >Priority: Major > Labels: sql-stability > Fix For: 2.8 > > Attachments: 3194.patch > > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630449#comment-16630449
]
Taras Ledkov commented on IGNITE-9686:
--
[~vozerov], please take a look at the path to forward the option
{{-XX:+IgnoreUnrecognizedVMOptions}}
[patch PR | https://github.com/apache/ignite/pull/4855]
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630445#comment-16630445
]
ASF GitHub Bot commented on IGNITE-9686:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/4855
IGNITE-9686: forward jvm parameter '-XX:+IgnoreUnrecognizedVMOptions' to
child process for tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9686
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4855.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 #4855
commit a3ddc76fb45e7e8d8abb58bdd8483d33cd2695a2
Author: tledkov-gridgain
Date: 2018-09-27T13:46:15Z
IGNITE-9686: forward jvm parameter '-XX:+IgnoreUnrecognizedVMOptions' to
child process for tests
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9721) NPE in IgniteAuthenticationProcessor$RefreshUsersStorageWorker.body
[
https://issues.apache.org/jira/browse/IGNITE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630278#comment-16630278
]
Oleg Ignatenko edited comment on IGNITE-9721 at 9/27/18 1:45 PM:
-
Checking the code suggests that there is a data race (data in {{metastorage}}
is supposed to be non null). Most probable reason for a race is that accessing
data relies on synchronization performed using non-final field (declared as
{{private GridFutureAdapter activateFut = new GridFutureAdapter<>();}}).
Also, in preliminary discussion [~tledkov-gridgain] pointed that current code
carries a risk of leaking {{this}} in constructor and proposed changes to
prevent that.
For the sake of completeness I also checked source code that supplies
troublesome data in {{GridCacheDatabaseSharedManager}} and discussed it with
[~agoncharuk]. As far as I could tell it is okay and I found no reason to
change it.
was (Author: oignatenko):
Checking the code suggests that there is a data race (data in {{metastorage}}
is supposed to be non null). Most probable reason for a race is that accessing
data relies on synchronization performed using non-final field (declared as
{{private GridFutureAdapter activateFut = new GridFutureAdapter<>();}}).
For the sake of completeness I also checked source code that supplies
troublesome data in {{GridCacheDatabaseSharedManager}} and discussed it with
[~agoncharuk]. As far as I could tell it is okay and I found no reason to
change it.
> NPE in IgniteAuthenticationProcessor$RefreshUsersStorageWorker.body
> ---
>
> Key: IGNITE-9721
> URL: https://issues.apache.org/jira/browse/IGNITE-9721
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Tests at Teamcity sometimes fail with NPE in
> {{IgniteAuthenticationProcessor}}.
> Example of failure (in test
> {{AuthenticationProcessorNodeRestartTest.test1kUsersNodeRestartServer}}) is
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=1945459=buildResultsDiv=IgniteTests24Java8_Cache7],
> and stacktrace looks as follows:
> {noformat}[2018-09-26
> 07:06:36,732][ERROR][auth-#6589%authentication.AuthenticationProcessorNodeRestartTest0%][IgniteAuthenticationProcessor]
> Runtime error caught during grid runnable execution: GridWorker
> [name=refresh-store,
> igniteInstanceName=authentication.AuthenticationProcessorNodeRestartTest0,
> finished=false, heartbeatTs=1537945595104, hashCode=733597684,
> interrupted=true,
> runner=auth-#6589%authentication.AuthenticationProcessorNodeRestartTest0%]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor$RefreshUsersStorageWorker.body(IgniteAuthenticationProcessor.java:1346)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> This might be either coding error (missing null check) or data race.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630419#comment-16630419
]
ASF GitHub Bot commented on IGNITE-9686:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4829
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9724) MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically.
Andrew Mashenkov created IGNITE-9724: Summary: MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically. Key: IGNITE-9724 URL: https://issues.apache.org/jira/browse/IGNITE-9724 Project: Ignite Issue Type: Bug Components: mvcc, sql Reporter: Andrew Mashenkov Fix For: 2.7 Attachments: hanging.txt CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed() hangs sporadically with PME. Exchange thread is waiting for partition released Query threads are waiting for TxTopologyVersionFuture. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-9686.
-
Resolution: Fixed
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9686) JDK9: pass JVM options to new process when start remote test node
[
https://issues.apache.org/jira/browse/IGNITE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9686:
Ignite Flags: (was: Docs Required)
> JDK9: pass JVM options to new process when start remote test node
> -
>
> Key: IGNITE-9686
> URL: https://issues.apache.org/jira/browse/IGNITE-9686
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: jdk9
> Fix For: 2.7
>
>
> The JVM options must be passed to new process when remote test node is
> started.
> See {{GridAbstractTest#startRemoteGrid}} methods.
> Affects tests:
> {code}
> GridClosureProcessorRemoteTest
> IgniteHadoopFileSystemClientBasedOpenTest
> IgniteWalRecoveryTest
> IgniteWalRecoveryWithCompactionTest
> IgnitePdsRebalancingOnNotStableTopologyTest
> CacheScanQueryFailoverTest
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
