[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 11:31 PM: Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. I see two approaches for now: First: To make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. It solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed And helps to reuse current ProxyInvocationHandler. But it blocks the user thread that calls the service method. In case of an invalid service name user thread will be blocked forever. Until user thread will be interrupted. Second: To create service processor specific ProxyInvocationHandler. In this case, if demanded service was not registered at the moment of invokeMethod invocation, exception will be thrown. So we will wait only for already registered services initialization and receiving full message from coordinator. If timeout equals 0, we will wait until service will be completely initialized or failed. WDYT? was (Author: petrovmikhail): Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is
[jira] [Created] (IGNITE-12960) Remove twitter module tests from Teamcity Streamers TestSuite
Saikat Maitra created IGNITE-12960: -- Summary: Remove twitter module tests from Teamcity Streamers TestSuite Key: IGNITE-12960 URL: https://issues.apache.org/jira/browse/IGNITE-12960 Project: Ignite Issue Type: Sub-task Components: streaming Reporter: Saikat Maitra Remove twitter module tests from Teamcity Streamers TestSuite This issue is related to https://issues.apache.org/jira/browse/IGNITE-12357 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[ https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-12788. -- Resolution: Fixed merged to 2.8.1 branch > Cluster achieved fully rebalanced (PME-free ready) state metric > --- > > Key: IGNITE-12788 > URL: https://issues.apache.org/jira/browse/IGNITE-12788 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, there is no metric responsible for "PME-free ready state achieved" > delivery. > {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such > metric. > Seems, we should update metric on each > {{GridDhtPartitionsExchangeFuture#onDone}}. > P.s. Late Affinity Assignment should always set {{true}} to metric value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12925) Flaky tests for continuous query metrics.
[ https://issues.apache.org/jira/browse/IGNITE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093884#comment-17093884 ] Amelchev Nikita commented on IGNITE-12925: -- [~PetrovMikhail], LGTM. > Flaky tests for continuous query metrics. > - > > Key: IGNITE-12925 > URL: https://issues.apache.org/jira/browse/IGNITE-12925 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > It is needed to fix flaky tests: > SystemViewSelfTest.testContinuousQuery test – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead] > SqlViewExporterSpiTest#testContinuousQuery – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50] > JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test > scenario is used as above. > It seems that QueryCursor#close method > gives no guarantees that CQ routine will be cleared from all nodes before > its returning. This behavior is due to StopRoutineDiscoveryMessage is > immutable and so StopRoutineAckDiscoveryMessage can be received > (QueryCoursor#close method returns) before > GridContinuousProcessor#processStopRequest completion on all nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12958) Add licenses check to Travis configuration
[ https://issues.apache.org/jira/browse/IGNITE-12958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12958: - Fix Version/s: 2.9 > Add licenses check to Travis configuration > -- > > Key: IGNITE-12958 > URL: https://issues.apache.org/jira/browse/IGNITE-12958 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > 1. Add licenses check to Travis configuration > 2. Make checks on the compile lifecycle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12959) Add support for GenericWhitespace to checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12959: - Fix Version/s: 2.9 > Add support for GenericWhitespace to checkstyle rules > - > > Key: IGNITE-12959 > URL: https://issues.apache.org/jira/browse/IGNITE-12959 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty > lines conventions. > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12925) Flaky tests for continuous query metrics.
[ https://issues.apache.org/jira/browse/IGNITE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-12925: Summary: Flaky tests for continuous query metrics. (was: Flaky test SystemViewSelfTest.testContinuousQuery.) > Flaky tests for continuous query metrics. > - > > Key: IGNITE-12925 > URL: https://issues.apache.org/jira/browse/IGNITE-12925 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > It is needed to fix flaky tests: > SystemViewSelfTest.testContinuousQuery test – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead] > SqlViewExporterSpiTest#testContinuousQuery – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50] > JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test > scenario is used as above. > It seems that QueryCursor#close method > gives no guarantees that CQ routine will be cleared from all nodes before > its returning. This behavior is due to StopRoutineDiscoveryMessage is > immutable and so StopRoutineAckDiscoveryMessage can be received > (QueryCoursor#close method returns) before > GridContinuousProcessor#processStopRequest completion on all nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12925) Flaky test SystemViewSelfTest.testContinuousQuery.
[ https://issues.apache.org/jira/browse/IGNITE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-12925: Description: It is needed to fix flaky tests: SystemViewSelfTest.testContinuousQuery test – [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead] SqlViewExporterSpiTest#testContinuousQuery – [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50] JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test scenario is used as above. It seems that QueryCursor#close method gives no guarantees that CQ routine will be cleared from all nodes before its returning. This behavior is due to StopRoutineDiscoveryMessage is immutable and so StopRoutineAckDiscoveryMessage can be received (QueryCoursor#close method returns) before GridContinuousProcessor#processStopRequest completion on all nodes. was: It is needed to fix SystemViewSelfTest.testContinuousQuery test, which is flaky – [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]. It seems that QueryCursor#close method gives no guarantees that CQ routine will be cleared from all nodes before its returning. This behavior is due to StopRoutineDiscoveryMessage is immutable and so StopRoutineAckDiscoveryMessage can be received (QueryCoursor#close method returns) before GridContinuousProcessor#processStopRequest completion on all nodes. > Flaky test SystemViewSelfTest.testContinuousQuery. > -- > > Key: IGNITE-12925 > URL: https://issues.apache.org/jira/browse/IGNITE-12925 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > It is needed to fix flaky tests: > SystemViewSelfTest.testContinuousQuery test – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead] > SqlViewExporterSpiTest#testContinuousQuery – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-5486808152570919536=START_DATE_DESC_IgniteTests24Java8=pull%2F7622%2Fhead=50] > JmxExporterSpiTest#testContinuousQuery – no failures so far but the same test > scenario is used as above. > It seems that QueryCursor#close method > gives no guarantees that CQ routine will be cleared from all nodes before > its returning. This behavior is due to StopRoutineDiscoveryMessage is > immutable and so StopRoutineAckDiscoveryMessage can be received > (QueryCoursor#close method returns) before > GridContinuousProcessor#processStopRequest completion on all nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12959) Add support for GenericWhitespace to checkstyle rules
Amelchev Nikita created IGNITE-12959: Summary: Add support for GenericWhitespace to checkstyle rules Key: IGNITE-12959 URL: https://issues.apache.org/jira/browse/IGNITE-12959 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty lines conventions. https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12925) Flaky test SystemViewSelfTest.testContinuousQuery.
[ https://issues.apache.org/jira/browse/IGNITE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12925: --- Assignee: Mikhail Petrov > Flaky test SystemViewSelfTest.testContinuousQuery. > -- > > Key: IGNITE-12925 > URL: https://issues.apache.org/jira/browse/IGNITE-12925 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > > It is needed to fix SystemViewSelfTest.testContinuousQuery test, which is > flaky – [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2075278944640125900=testDetails_IgniteTests24Java8=pull%2F7696%2Fhead]. > It seems that QueryCursor#close method > gives no guarantees that CQ routine will be cleared from all nodes before > its returning. This behavior is due to StopRoutineDiscoveryMessage is > immutable and so StopRoutineAckDiscoveryMessage can be received > (QueryCoursor#close method returns) before > GridContinuousProcessor#processStopRequest completion on all nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12958) Add licenses check to Travis configuration
Amelchev Nikita created IGNITE-12958: Summary: Add licenses check to Travis configuration Key: IGNITE-12958 URL: https://issues.apache.org/jira/browse/IGNITE-12958 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita 1. Add licenses check to Travis configuration 2. Make checks on the compile lifecycle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12902) Concurrent modification in time to iterate by events
[ https://issues.apache.org/jira/browse/IGNITE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093782#comment-17093782 ] Alexey Goncharuk commented on IGNITE-12902: --- Merged to master, thanks! > Concurrent modification in time to iterate by events > > > Key: IGNITE-12902 > URL: https://issues.apache.org/jira/browse/IGNITE-12902 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > {code:java} > [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20 > 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop > processor: GridProcessorAdapter [] > [10:20:37]W: [org.apache.ignite:ignite-core] > java.util.ConcurrentModificationException > [10:20:37]W: [org.apache.ignite:ignite-core] at > java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) > [10:20:37]W: [org.apache.ignite:ignite-core] at > java.util.ArrayList$Itr.next(ArrayList.java:859) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120) > [10:20:37]W: [org.apache.ignite:ignite-core] at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code} > In that place we are going over event’s collection, looking for server > leave’s event: > {code:java} > for (DiscoveryEvent evt : evts.events()) { > if (serverLeftEvent(evt)) { > for (CacheGroupContext grp : cctx.cache().cacheGroups()) > grp.affinityFunction().removeNode(evt.eventNode().id()); > } > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png
[ https://issues.apache.org/jira/browse/IGNITE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093747#comment-17093747 ] Pavel Tupitsyn commented on IGNITE-12957: - Merged to master: b5857399a9dac671ddaadd0cabfa246393af6a43 > .NET: Docs have unavailable resource logo3.png > -- > > Key: IGNITE-12957 > URL: https://issues.apache.org/jira/browse/IGNITE-12957 > Project: Ignite > Issue Type: New Feature > Components: documentation, platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png
[ https://issues.apache.org/jira/browse/IGNITE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-12957. - Resolution: Fixed > .NET: Docs have unavailable resource logo3.png > -- > > Key: IGNITE-12957 > URL: https://issues.apache.org/jira/browse/IGNITE-12957 > Project: Ignite > Issue Type: New Feature > Components: documentation, platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12957) .NET: Docs have unavailable resource logo3.png
Pavel Tupitsyn created IGNITE-12957: --- Summary: .NET: Docs have unavailable resource logo3.png Key: IGNITE-12957 URL: https://issues.apache.org/jira/browse/IGNITE-12957 Project: Ignite Issue Type: New Feature Components: documentation, platforms Affects Versions: 2.8 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads
[ https://issues.apache.org/jira/browse/IGNITE-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-12956: - Assignee: Anton Vinogradov > Fully prepared TX rolled back on recovery if TX coordinator failed and some > primary has only reads > -- > > Key: IGNITE-12956 > URL: https://issues.apache.org/jira/browse/IGNITE-12956 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > We have 3 nodes with partitioned cache with 2 backups. > A - tx coordinator. > B and C - other nodes. > Let's start tx from A and perform > {noformat} > cache.put(primaryKeyA, someVal); > cache.get(primaryKeyB; > tx.prepare(); > {noformat} > then kill A. > Expected: tx recovered and > {noformat} > cache.get(primaryKeyA)!=null > {noformat} > Actual: tx rolled back and > and > {noformat} > cache.get(primaryKeyA)==null > {noformat} > Reason: Node C has only 1 active transaction (because reads not propagated to > backup), but expect to have 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads
Anton Vinogradov created IGNITE-12956: - Summary: Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads Key: IGNITE-12956 URL: https://issues.apache.org/jira/browse/IGNITE-12956 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We have 3 nodes with partitioned cache with 2 backups. A - tx coordinator. B and C - other nodes. Let's start tx from A and perform {noformat} cache.put(primaryKeyA, someVal); cache.get(primaryKeyB; tx.prepare(); {noformat} then kill A. Expected: tx recovered and {noformat} cache.get(primaryKeyA)!=null {noformat} Actual: tx rolled back and and {noformat} cache.get(primaryKeyA)==null {noformat} Reason: Node C has only 1 active transaction (because reads not propagated to backup), but expect to have 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.
[ https://issues.apache.org/jira/browse/IGNITE-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093698#comment-17093698 ] Ignite TC Bot commented on IGNITE-12938: {panel:title=Branch: [pull/7743/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5264047buildTypeId=IgniteTests24Java8_RunAll] > control.sh utility commands: IdleVerify and ValidateIndexes use eventual > payload check. > --- > > Key: IGNITE-12938 > URL: https://issues.apache.org/jira/browse/IGNITE-12938 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > > "--cache idle_verify" and "--cache validate_indexes" commands of *control.sh* > utility use eventual payload check during execution. This can lead to > execution concurrently with active payload and no errors like : "Checkpoint > with dirty pages started! Cluster not idle" will be triggered. Additionally > current functional miss check on caches without persistence. Remove old > functionality from PageMemory and move it into update counters usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
[ https://issues.apache.org/jira/browse/IGNITE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093696#comment-17093696 ] Maxim Muzafarov commented on IGNITE-12954: -- [~zaleslaw] Thank you, merged to the master branch. > Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser > -- > > Key: IGNITE-12954 > URL: https://issues.apache.org/jira/browse/IGNITE-12954 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, there are some redundant suppressions for the checkstyle rules > which can be removed: > {code} > files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/> > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[ https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093695#comment-17093695 ] Mikhail Petrov commented on IGNITE-12788: - [~nizhikov], I have created PR with cherry-pick - [1]. TC bot report - [2]. [1] - [https://github.com/apache/ignite/pull/7738] [2] - [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7738%2Fhead=Latest=ignite-2.8.1] > Cluster achieved fully rebalanced (PME-free ready) state metric > --- > > Key: IGNITE-12788 > URL: https://issues.apache.org/jira/browse/IGNITE-12788 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, there is no metric responsible for "PME-free ready state achieved" > delivery. > {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such > metric. > Seems, we should update metric on each > {{GridDhtPartitionsExchangeFuture#onDone}}. > P.s. Late Affinity Assignment should always set {{true}} to metric value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
[ https://issues.apache.org/jira/browse/IGNITE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12954: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser > -- > > Key: IGNITE-12954 > URL: https://issues.apache.org/jira/browse/IGNITE-12954 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Currently, there are some redundant suppressions for the checkstyle rules > which can be removed: > {code} > files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/> > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
[ https://issues.apache.org/jira/browse/IGNITE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093687#comment-17093687 ] Alexey Zinoviev commented on IGNITE-12954: -- [~mmuzaf] Yes, looks good for me > Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser > -- > > Key: IGNITE-12954 > URL: https://issues.apache.org/jira/browse/IGNITE-12954 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Currently, there are some redundant suppressions for the checkstyle rules > which can be removed: > {code} > files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/> > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
[ https://issues.apache.org/jira/browse/IGNITE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093680#comment-17093680 ] Maxim Muzafarov commented on IGNITE-12954: -- [~zaleslaw] Hello, can you take a look at my changes? > Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser > -- > > Key: IGNITE-12954 > URL: https://issues.apache.org/jira/browse/IGNITE-12954 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, there are some redundant suppressions for the checkstyle rules > which can be removed: > {code} > files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/> > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12954) Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser
[ https://issues.apache.org/jira/browse/IGNITE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093665#comment-17093665 ] Ignite TC Bot commented on IGNITE-12954: {panel:title=Branch: [pull/7736/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5262722buildTypeId=IgniteTests24Java8_RunAll] > Remove checkstyle suppression for XGBoostModelLexer,XGBoostModelParser > -- > > Key: IGNITE-12954 > URL: https://issues.apache.org/jira/browse/IGNITE-12954 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, there are some redundant suppressions for the checkstyle rules > which can be removed: > {code} > files="XGBoostModelLexer\.java|XGBoostModelParser\.java"/> > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[ https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093627#comment-17093627 ] Ignite TC Bot commented on IGNITE-12911: {panel:title=Branch: [pull/7742/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5264295buildTypeId=IgniteTests24Java8_RunAll] > B+Tree Corrupted exception when using a key extracted from a BinaryObject > value object --- and SQL enabled. > --- > > Key: IGNITE-12911 > URL: https://issues.apache.org/jira/browse/IGNITE-12911 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Reporter: Alexander Korenshteyn >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.9 > > Attachments: Employee.java, EmployeeId.java, ServerNode.java, > image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png, > image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png, > image-2020-04-21-17-16-46-381.png > > Time Spent: 10m > Remaining Estimate: 0h > > If a key is part of the value like so: > class key \{ ... } > class value > { private Key key getKey() } > cache = ignite.cache()*.withKeepBinary()* > the following scenario yields a B+ Tree exception: > 1. *Enable SQL via annotations or QueryEntities.* > key1= new Key() > value1 = new Value(key1) > cache.put(key1, value1) > BinaryObject val2 = cache.get(key1) > BinaryObject key2 = val2.field("key") > > *cache2.put(key2.toBuilder().build(), emp1); // OK!* > > *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree > iscorrupted ...* > user list: > > [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html] > *Reproducer – attached* > > his happens because: > CacheRowAdapter.readFullRow() reads the length > *int len = PageUtils.getInt(addr,off)* > *it returns 0 when val2.field("key") is used* > > *the data is written correctly in DataPageIO.writeDataPageIO():* > !image-2020-04-21-17-16-46-381.png! > > *but read incorrectly in CacheRowAdapter.readFullRow()* > !image-2020-04-21-17-16-29-107.png! > > > Exception: > [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is > corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, > val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, > indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: > model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, > departmentNumber=123], val: model.Employee [idHash=382762227, > hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId > [idHash=2021540695, hash=674030145, employeeNumber=65348765, > departmentNumber=123]] ][ John, Smith > class > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, > val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, > indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: > model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, > departmentNumber=123], val: model.Employee [idHash=382762227, > hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId > [idHash=2021540695, hash=674030145, employeeNumber=65348765, > departmentNumber=123]] ][ John, Smith ]] > at > org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836) > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447) > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394) > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437) > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016) > at >
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 3:12 PM: --- Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. I see two approaches for now: First: To make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. It solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed And helps to reuse current ProxyInvocationHandler. But it blocks the user thread that calls the service method. In case of an invalid service name user thread will be blocked forever. Until user thread will be interrupted. Second: To create service specific ProxyInvocationHandler. In this case, if demanded service was not registered at the moment of invokeMethod invocation, exception will be thrown. So we will wait only for already registered services initialization and receiving full message from coordinator. If timeout equals 0, we will wait until service will be completely initialized or failed. WDYT? was (Author: petrovmikhail): Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The
[jira] [Commented] (IGNITE-12953) Add support for SingleSpaceSeparator to checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093600#comment-17093600 ] Maxim Muzafarov commented on IGNITE-12953: -- [~NSAmelchev] LGTM, Merged to the master branch. Thank you for your contribution. > Add support for SingleSpaceSeparator to checkstyle rules > > > Key: IGNITE-12953 > URL: https://issues.apache.org/jira/browse/IGNITE-12953 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty > lines conventions. > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 2:52 PM: --- Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. I see two approaches for now: First: To make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. It solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed And helps to reuse current ProxyInvocationHandler. But it blocks the user thread that calls the service method. In case of an invalid service name user thread will be blocked forever. Until user thread will be interrupted. Second: To create service specific ProxyInvocationHandler with described by you logic. In this case, if demanded service was not registered at the moment of invokeMethod invocation, exception will be thrown. So we will wait only for already registered services initialization and receiving full message from coordinator. WDYT? was (Author: petrovmikhail): Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 2:51 PM: --- Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. I see two approaches for now: First: To make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. It solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed And helps to reuse current ProxyInvocationHandler. But it blocks the user thread that calls the service method. In case of an invalid service name user thread will be blocked forever. Until user thread will be interrupted. Second: To create service specific ProxyInvocationHandler with described by you logic. In this case, if demanded service was not registered on the moment of invokeMethod invocation, exception will be thrown. So we will wait only for already registered services initialization and receiving full message from coordinator. WDYT? was (Author: petrovmikhail): Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for
[jira] [Resolved] (IGNITE-12936) .NET inspections fail on master
[ https://issues.apache.org/jira/browse/IGNITE-12936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego resolved IGNITE-12936. -- Resolution: Duplicate Fixed by IGNITE-12940 > .NET inspections fail on master > --- > > Key: IGNITE-12936 > URL: https://issues.apache.org/jira/browse/IGNITE-12936 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The following suites are failing: > [Platform .NET (NuGet) > |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E] > [Platform .NET (Inspections) > |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetInspections?branch=%3Cdefault%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov edited comment on IGNITE-12894 at 4/27/20, 1:29 PM: --- Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. So I propose to make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. In case of using IgniteServiceProcessor, it helps to avoid using busy-wait loop for topology obtaining. And solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed But it blocks the user thread that calls the service method. In case of an invalid service name user thread will be blocked forever. Until user thread will be interrupted. WDYT? was (Author: petrovmikhail): Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid,
[jira] [Created] (IGNITE-12955) Document a new command control.sh --cache check_index_inline_sizes
Sergey Antonov created IGNITE-12955: --- Summary: Document a new command control.sh --cache check_index_inline_sizes Key: IGNITE-12955 URL: https://issues.apache.org/jira/browse/IGNITE-12955 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Fix For: 2.9 Please look at IGNITE-12942 and devlist discussion linked to IGNITE-12942 for all information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12953) Add support for SingleSpaceSeparator to checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093472#comment-17093472 ] Ignite TC Bot commented on IGNITE-12953: {panel:title=Branch: [pull/7734/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5262838buildTypeId=IgniteTests24Java8_RunAll] > Add support for SingleSpaceSeparator to checkstyle rules > > > Key: IGNITE-12953 > URL: https://issues.apache.org/jira/browse/IGNITE-12953 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add a new rule to checkstyle according to Apache Ignite Whitespaces and empty > lines conventions. > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: Cannot enable read-through (loader or store is not provided) for cache
[ https://issues.apache.org/jira/browse/IGNITE-12898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-12898: -- Fix Version/s: 2.9 > Server node with CacheStore fails to re-join the cluster: Cannot enable > read-through (loader or store is not provided) for cache > > > Key: IGNITE-12898 > URL: https://issues.apache.org/jira/browse/IGNITE-12898 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Ivan Daschinskiy >Priority: Major > Labels: sbcf > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > If a cache with external persistence is dynamically created on a non-affinity > node then the cache affinity node cannot join the cluster after restart. > h2. Repro Steps > # Run an "empty" Ignite node where no cache is going to be started > # Run a cache affinity node having the "ROLE" attribute set to "DATA" > # Create the cache from the "empty" node and use a Node Filter to limit the > cache to the "data" node. External persistence is configured for the cache. > # Restart the "data" node > h3. Actual Result > {{IgniteCheckedException: Cannot enable read-through (loader or store is not > provided) for cache}} > h2. Reproducer > h3. Reproducer.java > {code:java} > public class Reproducer { > @Test > public void test() throws Exception { > final String DB_URL = "jdbc:h2:mem:test"; > final String ENTITY_NAME = "Person"; > Function igniteCfgFactory = instanceName > -> > new IgniteConfiguration() > .setIgniteInstanceName(instanceName) > .setDiscoverySpi(new TcpDiscoverySpi() > .setIpFinder(new > TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))) > ); > // 1. Run an "empty" Ignite node where no cache is going to be started > try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", > ""); > Statement dbStmt = dbConn.createStatement(); > Ignite emptyNode = > Ignition.start(igniteCfgFactory.apply("emptyyNode"))) { > // 2. Run a "Person" cache affinity node having the "ROLE" > attribute set to "DATA" > Map dataNodeAttrs = new HashMap<>(1); > dataNodeAttrs.put(DataNodeFilter.ATTR_NAME, > DataNodeFilter.ATTR_VAL); > Ignite dataNode = > Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs)); > // 3. Create the "Person" cache from the "empty" node and use a > Node Filter to limit the cache to the > // "data" node. External persistence to the "Person" table in H2 > DB is configured for the cache. > dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY > KEY, name varchar)"); > CacheJdbcPojoStoreFactory > igniteStoreFactory = new CacheJdbcPojoStoreFactory<>(); > igniteStoreFactory.setDataSourceFactory(() -> > JdbcConnectionPool.create(DB_URL, "sa", "")) > .setTypes( > new JdbcType() > .setCacheName(ENTITY_NAME) > .setDatabaseTable(ENTITY_NAME) > .setKeyType(Integer.class) > .setValueType(ENTITY_NAME) > .setKeyFields(new > JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id")) > .setValueFields( > new JdbcTypeField(java.sql.Types.INTEGER, "id", > Integer.class, "id"), > new JdbcTypeField(java.sql.Types.VARCHAR, "name", > String.class, "name") > ) > ); > CacheConfiguration cacheCfg = > new CacheConfiguration(ENTITY_NAME) > .setCacheMode(CacheMode.REPLICATED) > .setCacheStoreFactory(igniteStoreFactory) > .setWriteThrough(true) > .setReadThrough(true) > .setNodeFilter(new DataNodeFilter()); > emptyNode.createCache(cacheCfg).withKeepBinary(); > // 4. Restart the "data" node > dataNode.close(); > dataNode = > Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs)); > dataNode.close(); > } > } > private static class DataNodeFilter implements > IgnitePredicate { > public static final String ATTR_NAME = "ROLE"; > public static final String ATTR_VAL = "DATA"; > @Override public boolean apply(ClusterNode node) { > Object role =
[jira] [Updated] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12583: - Fix Version/s: 2.9 > Parametrization of JdbcThinBulkLoadAbstractSelfTest > --- > > Key: IGNITE-12583 > URL: https://issues.apache.org/jira/browse/IGNITE-12583 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.9 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended > several times using just parameter-assigning-getters like > {code:java} > protected CacheMode cacheMode() { return CacheMode.REPLICATED; } > protected CacheAtomicityMode atomicityMode() { return > CacheAtomicityMode.TRANSACTIONAL;} > protected boolean nearCache() { return false; } > {code} > Should go with params instead. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093288#comment-17093288 ] Alexey Goncharuk commented on IGNITE-12583: --- [~vladsz83] [~nizhikov] can you update the fixVersion? > Parametrization of JdbcThinBulkLoadAbstractSelfTest > --- > > Key: IGNITE-12583 > URL: https://issues.apache.org/jira/browse/IGNITE-12583 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 3h 40m > Remaining Estimate: 0h > > org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended > several times using just parameter-assigning-getters like > {code:java} > protected CacheMode cacheMode() { return CacheMode.REPLICATED; } > protected CacheAtomicityMode atomicityMode() { return > CacheAtomicityMode.TRANSACTIONAL;} > protected boolean nearCache() { return false; } > {code} > Should go with params instead. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12917) SQL: print warning log message when query's result is big
[ https://issues.apache.org/jira/browse/IGNITE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093235#comment-17093235 ] Andrey Mashenkov commented on IGNITE-12917: --- [~tledkov-gridgain], lgtm, merges to master. > SQL: print warning log message when query's result is big > - > > Key: IGNITE-12917 > URL: https://issues.apache.org/jira/browse/IGNITE-12917 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We have to track queries with big result set. > Print warning log message when query's result is bigger than threshold > specified by JMX. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime
[ https://issues.apache.org/jira/browse/IGNITE-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093230#comment-17093230 ] Pavel Tupitsyn commented on IGNITE-7276: [~agoncharuk] done, this will be in the next non-patch release, likely 2.9 > .NET: Enable/disable cache statistics in runtime > > > Key: IGNITE-7276 > URL: https://issues.apache.org/jira/browse/IGNITE-7276 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, newbie > Fix For: 2.9 > > Time Spent: 1h > Remaining Estimate: 0h > > {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}. > See IGNITE-369. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime
[ https://issues.apache.org/jira/browse/IGNITE-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-7276: --- Fix Version/s: 2.9 > .NET: Enable/disable cache statistics in runtime > > > Key: IGNITE-7276 > URL: https://issues.apache.org/jira/browse/IGNITE-7276 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, newbie > Fix For: 2.9 > > Time Spent: 1h > Remaining Estimate: 0h > > {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}. > See IGNITE-369. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[ https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10940: - Release Note: C++ platform no longer requires autotools to build. > Supply pre-built ./configure with Apache Ignite releases > > > Key: IGNITE-10940 > URL: https://issues.apache.org/jira/browse/IGNITE-10940 > Project: Ignite > Issue Type: Improvement > Components: build, platforms >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: c++ > Fix For: 2.9 > > > Right now we have the following build steps for C++ in docs: > {code} > cd modules/platforms/cpp > libtoolize && aclocal && autoheader && automake --add-missing && autoreconf > ./configure > make > sudo make install > {code} > However, it is customary for C++ projects to ship release tarballs with first > step already done. ./configure should be pre-built and libtoolize, etc, are > already ran since you should not force user to install them, and the process > of their application is deterministic. > I suggest we add libtoolize && etc step to release builds so that user's > first step will be ./configure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7828: - Fix Version/s: (was: 2.8) > Adopt yardstick tests for the new version of kNN regression algorithm > - > > Key: IGNITE-7828 > URL: https://issues.apache.org/jira/browse/IGNITE-7828 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7828: - Fix Version/s: 2.8 > Adopt yardstick tests for the new version of kNN regression algorithm > - > > Key: IGNITE-7828 > URL: https://issues.apache.org/jira/browse/IGNITE-7828 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7276) .NET: Enable/disable cache statistics in runtime
[ https://issues.apache.org/jira/browse/IGNITE-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093218#comment-17093218 ] Alexey Goncharuk commented on IGNITE-7276: -- [~ptupitsyn] Can you please update the fixVersion? Which release will this improvement get in? > .NET: Enable/disable cache statistics in runtime > > > Key: IGNITE-7276 > URL: https://issues.apache.org/jira/browse/IGNITE-7276 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, newbie > Time Spent: 1h > Remaining Estimate: 0h > > {{ICache.EnableStatistics}}, {{ICluster.EnableStatistics}}. > See IGNITE-369. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[ https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12788: --- Assignee: Mikhail Petrov (was: Nikolay Izhikov) > Cluster achieved fully rebalanced (PME-free ready) state metric > --- > > Key: IGNITE-12788 > URL: https://issues.apache.org/jira/browse/IGNITE-12788 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, there is no metric responsible for "PME-free ready state achieved" > delivery. > {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such > metric. > Seems, we should update metric on each > {{GridDhtPartitionsExchangeFuture#onDone}}. > P.s. Late Affinity Assignment should always set {{true}} to metric value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes
[ https://issues.apache.org/jira/browse/IGNITE-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093204#comment-17093204 ] Nikolay Izhikov commented on IGNITE-12806: -- Hello, [~YAMolochkov]. It seems to me like a minor issue. I will move it to 2.9 release, because, 2.8.1 is a bugfix release. > Incorret usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > --- > > Key: IGNITE-12806 > URL: https://issues.apache.org/jira/browse/IGNITE-12806 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Yaroslav Molochkov >Priority: Major > Labels: IEP-35 > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method > {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is > inverted and doesn't have any sense. In most cases usages of > {{Class.isAssignableFrom}} could be avoided. > See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} > instance in mentioned classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes
[ https://issues.apache.org/jira/browse/IGNITE-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12806: - Fix Version/s: (was: 2.8.1) 2.9 > Incorret usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > --- > > Key: IGNITE-12806 > URL: https://issues.apache.org/jira/browse/IGNITE-12806 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Yaroslav Molochkov >Priority: Minor > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method > {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is > inverted and doesn't have any sense. In most cases usages of > {{Class.isAssignableFrom}} could be avoided. > See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} > instance in mentioned classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes
[ https://issues.apache.org/jira/browse/IGNITE-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12806: - Priority: Minor (was: Major) > Incorret usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > --- > > Key: IGNITE-12806 > URL: https://issues.apache.org/jira/browse/IGNITE-12806 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Yaroslav Molochkov >Priority: Minor > Labels: IEP-35 > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method > {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is > inverted and doesn't have any sense. In most cases usages of > {{Class.isAssignableFrom}} could be avoided. > See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}} > instance in mentioned classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[ https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov reassigned IGNITE-12911: -- Assignee: Anton Kalashnikov > B+Tree Corrupted exception when using a key extracted from a BinaryObject > value object --- and SQL enabled. > --- > > Key: IGNITE-12911 > URL: https://issues.apache.org/jira/browse/IGNITE-12911 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Reporter: Alexander Korenshteyn >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.9 > > Attachments: Employee.java, EmployeeId.java, ServerNode.java, > image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png, > image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png, > image-2020-04-21-17-16-46-381.png > > > If a key is part of the value like so: > class key \{ ... } > class value > { private Key key getKey() } > cache = ignite.cache()*.withKeepBinary()* > the following scenario yields a B+ Tree exception: > 1. *Enable SQL via annotations or QueryEntities.* > key1= new Key() > value1 = new Value(key1) > cache.put(key1, value1) > BinaryObject val2 = cache.get(key1) > BinaryObject key2 = val2.field("key") > > *cache2.put(key2.toBuilder().build(), emp1); // OK!* > > *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree > iscorrupted ...* > user list: > > [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html] > *Reproducer – attached* > > his happens because: > CacheRowAdapter.readFullRow() reads the length > *int len = PageUtils.getInt(addr,off)* > *it returns 0 when val2.field("key") is used* > > *the data is written correctly in DataPageIO.writeDataPageIO():* > !image-2020-04-21-17-16-46-381.png! > > *but read incorrectly in CacheRowAdapter.readFullRow()* > !image-2020-04-21-17-16-29-107.png! > > > Exception: > [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is > corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, > val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, > indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: > model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, > departmentNumber=123], val: model.Employee [idHash=382762227, > hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId > [idHash=2021540695, hash=674030145, employeeNumber=65348765, > departmentNumber=123]] ][ John, Smith > class > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742, > val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE, > indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key: > model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765, > departmentNumber=123], val: model.Employee [idHash=382762227, > hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId > [idHash=2021540695, hash=674030145, employeeNumber=65348765, > departmentNumber=123]] ][ John, Smith ]] > at > org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836) > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447) > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394) > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437) > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:401) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2555) > at >
[jira] [Commented] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
[ https://issues.apache.org/jira/browse/IGNITE-12933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093175#comment-17093175 ] Sergey Kalashnikov commented on IGNITE-12933: - [~alex_pl], I've reviewed your changes, LGTM. > Node failed after put incorrect key class for indexed type to transactional > cache > - > > Key: IGNITE-12933 > URL: https://issues.apache.org/jira/browse/IGNITE-12933 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Node failed after put incorrect key class for indexed type to the > transactional cache when indexing is enabled. > Reproducer: > {code:java} > public class IndexedTypesTest extends GridCommonAbstractTest { > private boolean failed; > @Override protected IgniteConfiguration getConfiguration(String > igniteInstanceName) throws Exception { > return super.getConfiguration(igniteInstanceName) > .setFailureHandler((ignite, ctx) -> failed = true) > .setCacheConfiguration(new > CacheConfiguration<>(DEFAULT_CACHE_NAME) > .setAtomicityMode(TRANSACTIONAL) > .setIndexedTypes(String.class, String.class)); > } > @Test > public void testPutIndexedType() throws Exception { > Ignite ignite = startGrids(2); > for (int i = 0; i < 10; i++) { > try { > ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i); > } > catch (Exception ignore) { > } > } > assertFalse(failed); > } > } > {code} > Node failed with exception: > {noformat} > [2020-04-22 > 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources] > Critical system error detected. Will be handled accordingly to configured > handler > [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db, > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a > transaction has produced runtime exception]] > class > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > Committing a transaction has produced runtime exception > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update > index, incorrect key class [expCls=java.lang.String, > actualCls=java.lang.Integer] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223) > at >
[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[ https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093136#comment-17093136 ] Nikolay Izhikov commented on IGNITE-12788: -- Hello, [~PetrovMikhail] Can you, please, cherry-pick your fix for this issue [1] and create a PR to ignite-2.8.1 branch with it? > Cluster achieved fully rebalanced (PME-free ready) state metric > --- > > Key: IGNITE-12788 > URL: https://issues.apache.org/jira/browse/IGNITE-12788 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently, there is no metric responsible for "PME-free ready state achieved" > delivery. > {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such > metric. > Seems, we should update metric on each > {{GridDhtPartitionsExchangeFuture#onDone}}. > P.s. Late Affinity Assignment should always set {{true}} to metric value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
[ https://issues.apache.org/jira/browse/IGNITE-12933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-12933: -- Assignee: Aleksey Plekhanov > Node failed after put incorrect key class for indexed type to transactional > cache > - > > Key: IGNITE-12933 > URL: https://issues.apache.org/jira/browse/IGNITE-12933 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Node failed after put incorrect key class for indexed type to the > transactional cache when indexing is enabled. > Reproducer: > {code:java} > public class IndexedTypesTest extends GridCommonAbstractTest { > private boolean failed; > @Override protected IgniteConfiguration getConfiguration(String > igniteInstanceName) throws Exception { > return super.getConfiguration(igniteInstanceName) > .setFailureHandler((ignite, ctx) -> failed = true) > .setCacheConfiguration(new > CacheConfiguration<>(DEFAULT_CACHE_NAME) > .setAtomicityMode(TRANSACTIONAL) > .setIndexedTypes(String.class, String.class)); > } > @Test > public void testPutIndexedType() throws Exception { > Ignite ignite = startGrids(2); > for (int i = 0; i < 10; i++) { > try { > ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i); > } > catch (Exception ignore) { > } > } > assertFalse(failed); > } > } > {code} > Node failed with exception: > {noformat} > [2020-04-22 > 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources] > Critical system error detected. Will be handled accordingly to configured > handler > [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db, > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a > transaction has produced runtime exception]] > class > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > Committing a transaction has produced runtime exception > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update > index, incorrect key class [expCls=java.lang.String, > actualCls=java.lang.Integer] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2092) > at >
[jira] [Commented] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
[ https://issues.apache.org/jira/browse/IGNITE-12933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093117#comment-17093117 ] Ignite TC Bot commented on IGNITE-12933: {panel:title=Branch: [pull/7721/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5254748buildTypeId=IgniteTests24Java8_RunAll] > Node failed after put incorrect key class for indexed type to transactional > cache > - > > Key: IGNITE-12933 > URL: https://issues.apache.org/jira/browse/IGNITE-12933 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Node failed after put incorrect key class for indexed type to the > transactional cache when indexing is enabled. > Reproducer: > {code:java} > public class IndexedTypesTest extends GridCommonAbstractTest { > private boolean failed; > @Override protected IgniteConfiguration getConfiguration(String > igniteInstanceName) throws Exception { > return super.getConfiguration(igniteInstanceName) > .setFailureHandler((ignite, ctx) -> failed = true) > .setCacheConfiguration(new > CacheConfiguration<>(DEFAULT_CACHE_NAME) > .setAtomicityMode(TRANSACTIONAL) > .setIndexedTypes(String.class, String.class)); > } > @Test > public void testPutIndexedType() throws Exception { > Ignite ignite = startGrids(2); > for (int i = 0; i < 10; i++) { > try { > ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i); > } > catch (Exception ignore) { > } > } > assertFalse(failed); > } > } > {code} > Node failed with exception: > {noformat} > [2020-04-22 > 17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources] > Critical system error detected. Will be handled accordingly to configured > handler > [hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db, > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a > transaction has produced runtime exception]] > class > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > Committing a transaction has produced runtime exception > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update > index, incorrect key class [expCls=java.lang.String, > actualCls=java.lang.Integer] > at >
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[ https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093100#comment-17093100 ] Mikhail Petrov commented on IGNITE-12894: - Hi, [~daradurvs]. Thank you for clarification. After some researches, I found that [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] already has a similar mechanism as you mentioned. But it doesn't work correctly for the time being. [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L149] assumes that if [GridServiceProxy#waitTimeout|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L93] equals 0 (e.g. we use [IgniteServices#serviceProxy|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L592] for proxy obtaining) then waiting time is not limited at all. But at the same time, [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] assumes that if timeout argument equals 0 then NO waiting is needed. The same is for [GridServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java#L907]. Even if the behavior described above is considered valid, [GridServiceProxy#invokeMethod|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L169] throws an exception that is not ignored in case no node for the service was found. So no repeated attempts will be made. So I propose to make [IgniteServiceProcessor#serviceTopology|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L807] wait infinitely if timeout equals to 0. In case of using IgniteServiceProcessor, it helps to avoid using busy-wait loop for topology obtaining. And solves the following scenarios: * proxy obtaining method is called on node that did not receive service registration message * service is registered but service initialization or coordinator full message awaiting was not completed WDYT? > Cannot use IgniteAtomicSequence in Ignite services > -- > > Key: IGNITE-12894 > URL: https://issues.apache.org/jira/browse/IGNITE-12894 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Mikhail Petrov >Priority: Major > Labels: sbcf > > h2. Repro Steps > Execute the below steps in default service deployment mode and in > discovery-based service deployment mode. > Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to > switch to the discovery-based service deployment mode. > * Create a service initializing an {{IgniteAtomicService}} in method > {{Service#init()}} and using the {{IgniteAtomicService}} in a business method. > * Start an Ignite node with the service specified in the IgniteConfiguration > * Invoke the service's business method on the Ignite node > h3. Actual Result > h4. In Default Service Deployment Mode > Deadlock on the business method invocation > h4. In Discovery-Based Service Deployment Mode > The method invocation fails with {{IgniteException: Failed to find deployed > service: IgniteTestService}} > h2. Reproducer > h3. Test.java > {code:java} > public interface Test { > String sayHello(String name); > } > {code} > h3. IgniteTestService.java > {code:java} > public class IgniteTestService implements Test, Service { > private @IgniteInstanceResource Ignite ignite; > private IgniteAtomicSequence seq; > @Override public void cancel(ServiceContext ctx) { > } > @Override public void init(ServiceContext ctx) throws > InterruptedException { > seq = ignite.atomicSequence("TestSeq", 0, true); > } > @Override public void execute(ServiceContext ctx) { > } > @Override public String sayHello(String name) { > return "Hello, " + name + "! #" + seq.getAndIncrement(); > } > } > {code} > h3.
[jira] [Updated] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.
[ https://issues.apache.org/jira/browse/IGNITE-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-12938: Description: "--cache idle_verify" and "--cache validate_indexes" commands of *control.sh* utility use eventual payload check during execution. This can lead to execution concurrently with active payload and no errors like : "Checkpoint with dirty pages started! Cluster not idle" will be triggered. Additionally current functional miss check on caches without persistence. Remove old functionality from PageMemory and move it into update counters usage. (was: "Checkpoint with dirty pages started! Cluster not idle" - not idle detection command, but mechanism for check payload during commands execution. Additionally current functional miss check on caches without persistence. Remove old functionality from PageMemory and move it into update counters usage.) > control.sh utility commands: IdleVerify and ValidateIndexes use eventual > payload check. > --- > > Key: IGNITE-12938 > URL: https://issues.apache.org/jira/browse/IGNITE-12938 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > > "--cache idle_verify" and "--cache validate_indexes" commands of *control.sh* > utility use eventual payload check during execution. This can lead to > execution concurrently with active payload and no errors like : "Checkpoint > with dirty pages started! Cluster not idle" will be triggered. Additionally > current functional miss check on caches without persistence. Remove old > functionality from PageMemory and move it into update counters usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)