[jira] [Commented] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
[
https://issues.apache.org/jira/browse/IGNITE-23132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882927#comment-17882927
]
Mirza Aliev commented on IGNITE-23132:
--
Possible root cause https://github.com/sofastack/sofa-jraft/issues/1152
> java.lang.NullPointerException: null in LogId.compareTo when handle vote
> request
>
>
> Key: IGNITE-23132
> URL: https://issues.apache.org/jira/browse/IGNITE-23132
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_27645.log.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TC main has started to detect NullPointerException in builds logs. This
> happens in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens
> when node has already been stopped, but still handle vote request with
> already cleared states. We need to figure out and fix NPE.
> {noformat}
> [2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
> handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
> lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
> failed
> java.lang.NullPointerException: null
> at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23225) Add logging to LogManagerImpl
[
https://issues.apache.org/jira/browse/IGNITE-23225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-23225:
-
Description: We have an idea why NPE happens in
https://issues.apache.org/jira/browse/IGNITE-23132, seems like
{{LastLogIdClosure}} from
{{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#getLastLogId}} is
completed when {{LogManagerImpl.stopped}}, so
{{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#offerEvent}} leads
to completing {{LastLogIdClosure}} with {{RaftError.ESTOP}} and
{{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.LastLogIdClosure#lastLogId}}
is not set. To check that, we want to add some logging and monitor TC. (was:
We have an idea why NPE happens in
https://issues.apache.org/jira/browse/IGNITE-23132, seems like
{{LastLogIdClosure}} from
{{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#getLastLogId}} is
completed when {{this.stopped}})
> Add logging to LogManagerImpl
> -
>
> Key: IGNITE-23225
> URL: https://issues.apache.org/jira/browse/IGNITE-23225
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> We have an idea why NPE happens in
> https://issues.apache.org/jira/browse/IGNITE-23132, seems like
> {{LastLogIdClosure}} from
> {{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#getLastLogId}} is
> completed when {{LogManagerImpl.stopped}}, so
> {{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#offerEvent}} leads
> to completing {{LastLogIdClosure}} with {{RaftError.ESTOP}} and
> {{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.LastLogIdClosure#lastLogId}}
> is not set. To check that, we want to add some logging and monitor TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23225) Add logging to LogManagerImpl
[
https://issues.apache.org/jira/browse/IGNITE-23225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-23225:
-
Description: We have an idea why NPE happens in
https://issues.apache.org/jira/browse/IGNITE-23132, seems like
{{LastLogIdClosure}} from
{{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#getLastLogId}} is
completed when {{this.stopped}}
> Add logging to LogManagerImpl
> -
>
> Key: IGNITE-23225
> URL: https://issues.apache.org/jira/browse/IGNITE-23225
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> We have an idea why NPE happens in
> https://issues.apache.org/jira/browse/IGNITE-23132, seems like
> {{LastLogIdClosure}} from
> {{org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl#getLastLogId}} is
> completed when {{this.stopped}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23225) Add logging to LogManagerImpl
Mirza Aliev created IGNITE-23225: Summary: Add logging to LogManagerImpl Key: IGNITE-23225 URL: https://issues.apache.org/jira/browse/IGNITE-23225 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev Assignee: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22802) Gather requirements for replica factor 2 scenario
[ https://issues.apache.org/jira/browse/IGNITE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22802: - Attachment: Replica Factor 2_Majority unavalability requirements .docx > Gather requirements for replica factor 2 scenario > - > > Key: IGNITE-22802 > URL: https://issues.apache.org/jira/browse/IGNITE-22802 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Attachments: Replica Factor 2_Majority unavalability requirements > .docx > > > In this task we want to summarise all requirements for the scenario of tables > with replica factor 2. > > We want to have answers for several questions: > 1) What exactly we want from the scenario of replica factor 2, should it work > the same as we have in ignite 2, is this possible to do it easily or it > requires a lot of work? > 2) How can we implement this, taking into account that Raft, that is the base > replication algorithm, works unstable when its cluster has 2 nodes. > > As a result of this ticket, we should have a vision on the further work that > must be done on this track. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
[
https://issues.apache.org/jira/browse/IGNITE-23132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-23132:
Assignee: Mirza Aliev
> java.lang.NullPointerException: null in LogId.compareTo when handle vote
> request
>
>
> Key: IGNITE-23132
> URL: https://issues.apache.org/jira/browse/IGNITE-23132
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_27645.log.zip
>
>
> TC main has started to detect NullPointerException in builds logs. This
> happens in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens
> when node has already been stopped, but still handle vote request with
> already cleared states. We need to figure out and fix NPE.
> {noformat}
> [2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
> handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
> lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
> failed
> java.lang.NullPointerException: null
> at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23131) java.lang.AssertionError: The local node is outside of the replication group
[
https://issues.apache.org/jira/browse/IGNITE-23131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-23131:
Assignee: Mikhail Efremov
> java.lang.AssertionError: The local node is outside of the replication group
>
>
> Key: IGNITE-23131
> URL: https://issues.apache.org/jira/browse/IGNITE-23131
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Run_All_Other_27436.log.zip
>
>
> We've started to receive a lot of {{AssertionError}} during TC builds on
> main. These exceptions do not lead to failed tests, but must be investigated.
> {noformat}
> [2024-09-02T12:09:05,392][WARN
> ][%irlt_trisons_20002%tableManager-io-19][PartitionReplicaLifecycleManager]
> Unable to process pending assignments event
> java.lang.AssertionError: The local node is outside of the replication group
> [, stable=Assignments [nodes=HashSet [Assignment
> [consistentId=irlt_trisons_2, isPeer=true]], force=false,
> timestamp=113067880806875136], pending=Assignments [nodes=HashSet [Assignment
> [consistentId=irlt_trisons_20002, isPeer=true]], force=false,
> timestamp=113067880806875136], reduce=null, localName=irlt_trisons_20002].
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.isNodeInReducedStableOrPendingAssignments(PartitionReplicaLifecycleManager.java:1175)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$48(PartitionReplicaLifecycleManager.java:1015)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:872)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$49(PartitionReplicaLifecycleManager.java:1014)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
> [?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8444342?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildProblemsSection=true&expandCode+Inspection=true&expandBuildChangesSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
Mirza Aliev created IGNITE-23132:
Summary: java.lang.NullPointerException: null in LogId.compareTo
when handle vote request
Key: IGNITE-23132
URL: https://issues.apache.org/jira/browse/IGNITE-23132
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: _Integration_Tests_Module_Table_27645.log.zip
TC main has started to detect NullPointerException in builds logs. This happens
in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens when node
has already been stopped, but still handle vote request with already cleared
states. We need to figure out and fix NPE.
{noformat}
[2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
failed
java.lang.NullPointerException: null
at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23131) java.lang.AssertionError: The local node is outside of the replication group
Mirza Aliev created IGNITE-23131:
Summary: java.lang.AssertionError: The local node is outside of
the replication group
Key: IGNITE-23131
URL: https://issues.apache.org/jira/browse/IGNITE-23131
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: _Integration_Tests_Run_All_Other_27436.log.zip
We've started to receive a lot of {{AssertionError}} during TC builds on main.
These exceptions do not lead to failed tests, but must be investigated.
{noformat}
[2024-09-02T12:09:05,392][WARN
][%irlt_trisons_20002%tableManager-io-19][PartitionReplicaLifecycleManager]
Unable to process pending assignments event
java.lang.AssertionError: The local node is outside of the replication group [,
stable=Assignments [nodes=HashSet [Assignment [consistentId=irlt_trisons_2,
isPeer=true]], force=false, timestamp=113067880806875136], pending=Assignments
[nodes=HashSet [Assignment [consistentId=irlt_trisons_20002, isPeer=true]],
force=false, timestamp=113067880806875136], reduce=null,
localName=irlt_trisons_20002].
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.isNodeInReducedStableOrPendingAssignments(PartitionReplicaLifecycleManager.java:1175)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$48(PartitionReplicaLifecycleManager.java:1015)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:872)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$49(PartitionReplicaLifecycleManager.java:1014)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8444342?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildProblemsSection=true&expandCode+Inspection=true&expandBuildChangesSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22267) Improve Table API javadocs
[ https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-22267: Assignee: Mirza Aliev > Improve Table API javadocs > -- > > Key: IGNITE-22267 > URL: https://issues.apache.org/jira/browse/IGNITE-22267 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. Remove "started table" term, "table" is enough > 2. Remove "binary object" mentions > 3. Explain how KV view "splits" row data in two parts. It does not actually > operate on separate keys and values. > 4. Replace "Transaction or null to auto-commit" with "Transaction or null for > implicit transaction" > 5. Remove "@throws IgniteException If an unspecified platform exception has > occurred internally", it is not useful > 6. Declare order of tables in *tables()* and *tablesAsync()* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22923) Backport releases form 1.3.10 until 1.3.14 from the JRaft
[ https://issues.apache.org/jira/browse/IGNITE-22923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22923: - Description: In this task, we need to backport commits until 1.3.14 release from original JRaft repo. Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 was: In this task, we need to backport commits from 1.3.14 release from original JRaft repo. Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 > Backport releases form 1.3.10 until 1.3.14 from the JRaft > - > > Key: IGNITE-22923 > URL: https://issues.apache.org/jira/browse/IGNITE-22923 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task, we need to backport commits until 1.3.14 release from original > JRaft repo. > Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22923) Backport releases form 1.3.10 until 1.3.14 from the JRaft
[ https://issues.apache.org/jira/browse/IGNITE-22923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22923: - Summary: Backport releases form 1.3.10 until 1.3.14 from the JRaft (was: Backport 1.3.14 release form the JRaft) > Backport releases form 1.3.10 until 1.3.14 from the JRaft > - > > Key: IGNITE-22923 > URL: https://issues.apache.org/jira/browse/IGNITE-22923 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task, we need to backport commits from 1.3.14 release from original > JRaft repo. > Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22973) Analyse porting a diff between 1.3.10 and 1.3.14 from Jraft
Mirza Aliev created IGNITE-22973: Summary: Analyse porting a diff between 1.3.10 and 1.3.14 from Jraft Key: IGNITE-22973 URL: https://issues.apache.org/jira/browse/IGNITE-22973 Project: Ignite Issue Type: Task Reporter: Mirza Aliev Attachments: List of diff between original JRaft and our fork.xlsx We have a task for backporting releases since 1.3.10 to 1.3.14 from JRaft. As a first step we made a refinement where briefly analysed the scope, but we realised that we must deeply understand some changes. Commits could be found in the attachment. After this task is done we must understand fully all made changes from JRaft. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22599) Exception inside RAFT listener does not invoke falure handler
[
https://issues.apache.org/jira/browse/IGNITE-22599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22599:
Assignee: Mirza Aliev (was: Vladislav Pyatkov)
> Exception inside RAFT listener does not invoke falure handler
> -
>
> Key: IGNITE-22599
> URL: https://issues.apache.org/jira/browse/IGNITE-22599
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments:
> poc-tester-SERVER-192.168.1.41-id-0-2024-06-27-09-14-17-client.log.2
>
>
> h3. Motivation
> An exception that is thrown during handling RAFT command cannot be recovered,
> because a RAFT storage is already corrupted. This is a reason to call Falure
> handler:
> {code:java}
> failureProcessor.process(new FailureContext(CRITICAL_ERROR, err));
> {code}
> Currently, I do not see any FH invokation in the log, but many exception has
> been thrown.
> h3. Definition of done
> FH is invoked in the case where RAFT listener fails.
> h3. Implementation Notes
> * Failure handler should be invoked in case of critical exceptions while
> onWrite processing onRead processing, snapshotting and snapshot installation.
> * While testing, it's required to test all CMG MG and Partition listeners.
> * In order to ease testing, it worth implementing a test failure handler in
> order to detect that it was triggered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871296#comment-17871296
]
Mirza Aliev edited comment on IGNITE-22034 at 8/6/24 11:29 AM:
---
This test was removed in https://issues.apache.org/jira/browse/IGNITE-22806
was (Author: maliev):
This test were removed in https://issues.apache.org/jira/browse/IGNITE-22806
> ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
> --
>
> Key: IGNITE-22034
> URL: https://issues.apache.org/jira/browse/IGNITE-22034
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.waitForTablesCounterInMetastore(ItRebalanceTest.java:261)
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.testRebalanceTablesCounterForZone(ItRebalanceTest.java:199)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> The reason of this NPE is {{lastAssignmentsHolderForLog[0]}} equals {{null}}.
> We have not wait of appier a key in the metastorage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev resolved IGNITE-22034.
--
Resolution: Won't Fix
This test were removed in https://issues.apache.org/jira/browse/IGNITE-22806
> ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
> --
>
> Key: IGNITE-22034
> URL: https://issues.apache.org/jira/browse/IGNITE-22034
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.waitForTablesCounterInMetastore(ItRebalanceTest.java:261)
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.testRebalanceTablesCounterForZone(ItRebalanceTest.java:199)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> The reason of this NPE is {{lastAssignmentsHolderForLog[0]}} equals {{null}}.
> We have not wait of appier a key in the metastorage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22923) Backport 1.3.14 release form the JRaft
[ https://issues.apache.org/jira/browse/IGNITE-22923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22923: - Description: In this task, we need to backport commits from 1.3.14 release from original JRaft repo. Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 was: In this task, we need to backport commits from 1.3.14 release from original JRaft repo. > Backport 1.3.14 release form the JRaft > -- > > Key: IGNITE-22923 > URL: https://issues.apache.org/jira/browse/IGNITE-22923 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task, we need to backport commits from 1.3.14 release from original > JRaft repo. > Previous task for backport https://issues.apache.org/jira/browse/IGNITE-19960 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22923) Backport 1.3.14 release form the JRaft
Mirza Aliev created IGNITE-22923: Summary: Backport 1.3.14 release form the JRaft Key: IGNITE-22923 URL: https://issues.apache.org/jira/browse/IGNITE-22923 Project: Ignite Issue Type: Task Reporter: Mirza Aliev In this task, we need to backport commits from 1.3.14 release from original JRaft repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22833:
-
Description:
{noformat}
[10:10:14] : [:ignite-distribution-zones:test]
DistributionZoneCausalityDataNodesTest >
testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
int) > [1] 1, 1 STANDARD_ERROR
[10:10:14] : [:ignite-distribution-zones:test]
[2024-07-23T10:10:14,100][WARN
][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process catalog
event
[10:10:14] : [:ignite-distribution-zones:test]
java.lang.NullPointerException: null
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
*UPD*: After some investigation, I would suggest rewrite this test, so we don't
use mocks of metastorage and don't block some metastorage updates and wait for
further metastorage intereactions, like catalog updates. As an idea, we could
use {{org.apache.ignite.internal.test.WatchListenerInhibitor}} to block
reaction on changing of
{{org.apache.ignite.internal.distributionzones.DistributionZonesUtil#zonesLogicalTopologyKey}}
so that means that we will skip data nodes update as we wanted in the test
was:
{noformat}
[10:10:14] : [:ig
[jira] [Updated] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22833:
-
Description:
{noformat}
[10:10:14] : [:ignite-distribution-zones:test]
DistributionZoneCausalityDataNodesTest >
testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
int) > [1] 1, 1 STANDARD_ERROR
[10:10:14] : [:ignite-distribution-zones:test]
[2024-07-23T10:10:14,100][WARN
][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process catalog
event
[10:10:14] : [:ignite-distribution-zones:test]
java.lang.NullPointerException: null
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
*UPD*: After some investigation, I would suggest to rewrite this test, so we
don't use mocks of metastorage and don't block some metastorage updates and
wait for further metastorage intereactions, like catalog updates. As an idea,
we could use {{org.apache.ignite.internal.test.WatchListenerInhibitor}} to
block reaction on changing of
{{org.apache.ignite.internal.distributionzones.DistributionZonesUtil#zonesLogicalTopologyKey}}
so that means that we can skip data nodes update as we wanted in the test
was:
{noformat}
[10:10:14] : [:
[jira] [Updated] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22833:
-
Description:
{noformat}
[10:10:14] : [:ignite-distribution-zones:test]
DistributionZoneCausalityDataNodesTest >
testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
int) > [1] 1, 1 STANDARD_ERROR
[10:10:14] : [:ignite-distribution-zones:test]
[2024-07-23T10:10:14,100][WARN
][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process catalog
event
[10:10:14] : [:ignite-distribution-zones:test]
java.lang.NullPointerException: null
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
*UPD*: After some investigation, I would suggest to rewrite this test, so we
don't use mocks of metastorage and don't block some metastorage updates and
wait for further metastorage intereactions, like catalog updates. As an idea,
we could use {{org.apache.ignite.internal.test.WatchListenerInhibitor}} to
block reaction on changing of
{{org.apache.ignite.internal.distributionzones.DistributionZonesUtil#zonesLogicalTopologyKey}}
so that means that we will skip data nodes update as we wanted in the test
was:
{noformat}
[10:10:14] : [
[jira] [Updated] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22833:
-
Description:
{noformat}
[10:10:14] : [:ignite-distribution-zones:test]
DistributionZoneCausalityDataNodesTest >
testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
int) > [1] 1, 1 STANDARD_ERROR
[10:10:14] : [:ignite-distribution-zones:test]
[2024-07-23T10:10:14,100][WARN
][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process catalog
event
[10:10:14] : [:ignite-distribution-zones:test]
java.lang.NullPointerException: null
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
[10:10:14] : [:ignite-distribution-zones:test] at
java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
*UPD*: After some investigation, I would suggest rewrite this test, so we don't
use mocks of metastorage and don't block some metastorage updates and wait for
further metastorage intereactions, like catalog updates.
was:
{noformat}
[10:10:14] : [:ignite-distribution-zones:test]
DistributionZoneCausalityDataNodesTest >
testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
int) > [1] 1, 1 STANDARD_ERROR
[10:10:14] : [:ignite-distribution-zones:test]
[2024-07-23T10:10:14,100][WARN
][%test%meta
[jira] [Updated] (IGNITE-22834) Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown
[
https://issues.apache.org/jira/browse/IGNITE-22834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22834:
-
Description:
We need to mute
{{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown}}
because it fails with
{noformat}
[2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
Unable to count down partitions counter in metastore: 16_part_17
java.lang.AssertionError: null
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]{noformat}
It will be fixed in https://issues.apache.org/jira/browse/IGNITE-22806 by
removing counters logic at all
was:
We need to mute
{{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp}}
because it fails with
{noformat}
[2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
Unable to count down partitions counter in metastore: 16_part_17
java.lang.AssertionError: null
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]{noformat}
It will be fixed in https://issues.apache.org/jira/browse/IGNITE-22806 by
removing counters logic at all
> Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown
>
>
> Key: IGNITE-22834
> URL: https://issues.apache.org/jira/browse/IGNITE-22834
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to mute
> {{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown}}
> because it fails with
> {noformat}
> [2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
> Unable to count down partitions counter in metastore: 16_part_17
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:
[jira] [Updated] (IGNITE-22834) Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown
[
https://issues.apache.org/jira/browse/IGNITE-22834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22834:
-
Summary: Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown (was:
Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp)
> Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleDown
>
>
> Key: IGNITE-22834
> URL: https://issues.apache.org/jira/browse/IGNITE-22834
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to mute
> {{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp}}
> because it fails with
> {noformat}
> [2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
> Unable to count down partitions counter in metastore: 16_part_17
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]{noformat}
> It will be fixed in https://issues.apache.org/jira/browse/IGNITE-22806 by
> removing counters logic at all
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22834) Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp
[
https://issues.apache.org/jira/browse/IGNITE-22834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22834:
Assignee: Mirza Aliev
> Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp
> --
>
> Key: IGNITE-22834
> URL: https://issues.apache.org/jira/browse/IGNITE-22834
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to mute
> {{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp}}
> because it fails with
> {noformat}
> [2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
> Unable to count down partitions counter in metastore: 16_part_17
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]{noformat}
> It will be fixed in https://issues.apache.org/jira/browse/IGNITE-22806 by
> removing counters logic at all
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22834) Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp
Mirza Aliev created IGNITE-22834:
Summary: Mute ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp
Key: IGNITE-22834
URL: https://issues.apache.org/jira/browse/IGNITE-22834
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
We need to mute
{{org.apache.ignite.internal.table.ItEstimatedSizeTest#testEstimatedSizeAfterScaleUp}}
because it fails with
{noformat}
[2024-07-24T14:59:50,794][ERROR][%iest_teasd_0%rebalance-scheduler-12][RebalanceRaftGroupEventsListener]
Unable to count down partitions counter in metastore: 16_part_17
java.lang.AssertionError: null
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.countDownPartitionsFromZone(RebalanceRaftGroupEventsListener.java:260)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.lambda$onNewPeersConfigurationApplied$1(RebalanceRaftGroupEventsListener.java:238)
~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]{noformat}
It will be fixed in https://issues.apache.org/jira/browse/IGNITE-22806 by
removing counters logic at all
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22806) Investigate table counters problems
Mirza Aliev created IGNITE-22806: Summary: Investigate table counters problems Key: IGNITE-22806 URL: https://issues.apache.org/jira/browse/IGNITE-22806 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev For the purposes of the colocation feature, we have implemented counters for table rebalances from a zone https://issues.apache.org/jira/browse/IGNITE-21253. This solution has a lot of restrictions, like we cannot start a table in a zone if there is ongoing rebalance in this zone, or we cannot remove a table, etc. In general, solution was implemented as a workaround in we had a plan to remove it once colocation feature is implemented. Now we have several flaky tests because of some bugs in the counters implementation. 1) When we receive call back from raft that configuration of a group was applied, we count down counter, but we don't have a revision of MS and we cannot take actual counter for this event. It could lead to problems for some recovery scenarios or disaster recovery. 2) Also there is a NPE problem when we count down, because counter could be null, as we can see from `org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfPartitionIsLost` *Definition of done* * We must decide, should we rollback this feature, as long as corresponding logic for zone-based rebalance has already been implemented * We must invent some solution for Raft configuration applying and reading MS in that callbacks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22802) Gather requirements for replica factor 2 scenario
[ https://issues.apache.org/jira/browse/IGNITE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-22802: Assignee: Mirza Aliev > Gather requirements for replica factor 2 scenario > - > > Key: IGNITE-22802 > URL: https://issues.apache.org/jira/browse/IGNITE-22802 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task we want to summarise all requirements for the scenario of tables > with replica factor 2. > > We want to have answers for several questions: > 1) What exactly we want from the scenario of replica factor 2, should it work > the same as we have in ignite 2, is this possible to do it easily or it > requires a lot of work? > 2) How can we implement this, taking into account that Raft, that is the base > replication algorithm, works unstable when its cluster has 2 nodes. > > As a result of this ticket, we should have a vision on the further work that > must be done on this track. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22806) Investigate table counters problems
[ https://issues.apache.org/jira/browse/IGNITE-22806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-22806: Assignee: Mirza Aliev > Investigate table counters problems > --- > > Key: IGNITE-22806 > URL: https://issues.apache.org/jira/browse/IGNITE-22806 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > For the purposes of the colocation feature, we have implemented counters for > table rebalances from a zone > https://issues.apache.org/jira/browse/IGNITE-21253. > > This solution has a lot of restrictions, like we cannot start a table in a > zone if there is ongoing rebalance in this zone, or we cannot remove a table, > etc. > > In general, solution was implemented as a workaround in we had a plan to > remove it once colocation feature is implemented. > > Now we have several flaky tests because of some bugs in the counters > implementation. > 1) When we receive call back from raft that configuration of a group was > applied, we count down counter, but we don't have a revision of MS and we > cannot take actual counter for this event. It could lead to problems for some > recovery scenarios or disaster recovery. > > 2) Also there is a NPE problem when we count down, because counter could be > null, as we can see from > `org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfPartitionIsLost` > > *Definition of done* > * We must decide, should we rollback this feature, as long as corresponding > logic for zone-based rebalance has already been implemented > * We must invent some solution for Raft configuration applying and reading > MS in that callbacks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22802) Gather requirements for replica factor 2 scenario
[ https://issues.apache.org/jira/browse/IGNITE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22802: - Summary: Gather requirements for replica factor 2 scenario (was: Gather requirements for two replica scenario) > Gather requirements for replica factor 2 scenario > - > > Key: IGNITE-22802 > URL: https://issues.apache.org/jira/browse/IGNITE-22802 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task we want to summarise all requirements for the scenario of tables > with replica factor 2. > > We want to have answers for several questions: > 1) What exactly we want from the scenario of replica factor 2, should it work > the same as we have in ignite 2? > 2) How can we implement this, taking into account that Raft, that is the base > replication algorithm, works unstable when its cluster has 2 nodes. > > As a result of this ticket, we should have a vision on the further work that > must be done on this track. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22802) Gather requirements for replica factor 2 scenario
[ https://issues.apache.org/jira/browse/IGNITE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22802: - Description: In this task we want to summarise all requirements for the scenario of tables with replica factor 2. We want to have answers for several questions: 1) What exactly we want from the scenario of replica factor 2, should it work the same as we have in ignite 2, is this possible to do it easily or it requires a lot of work? 2) How can we implement this, taking into account that Raft, that is the base replication algorithm, works unstable when its cluster has 2 nodes. As a result of this ticket, we should have a vision on the further work that must be done on this track. was: In this task we want to summarise all requirements for the scenario of tables with replica factor 2. We want to have answers for several questions: 1) What exactly we want from the scenario of replica factor 2, should it work the same as we have in ignite 2? 2) How can we implement this, taking into account that Raft, that is the base replication algorithm, works unstable when its cluster has 2 nodes. As a result of this ticket, we should have a vision on the further work that must be done on this track. > Gather requirements for replica factor 2 scenario > - > > Key: IGNITE-22802 > URL: https://issues.apache.org/jira/browse/IGNITE-22802 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In this task we want to summarise all requirements for the scenario of tables > with replica factor 2. > > We want to have answers for several questions: > 1) What exactly we want from the scenario of replica factor 2, should it work > the same as we have in ignite 2, is this possible to do it easily or it > requires a lot of work? > 2) How can we implement this, taking into account that Raft, that is the base > replication algorithm, works unstable when its cluster has 2 nodes. > > As a result of this ticket, we should have a vision on the further work that > must be done on this track. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22802) Gather requirements for two replica scenario
Mirza Aliev created IGNITE-22802: Summary: Gather requirements for two replica scenario Key: IGNITE-22802 URL: https://issues.apache.org/jira/browse/IGNITE-22802 Project: Ignite Issue Type: Task Reporter: Mirza Aliev In this task we want to summarise all requirements for the scenario of tables with replica factor 2. We want to have answers for several questions: 1) What exactly we want from the scenario of replica factor 2, should it work the same as we have in ignite 2? 2) How can we implement this, taking into account that Raft, that is the base replication algorithm, works unstable when its cluster has 2 nodes. As a result of this ticket, we should have a vision on the further work that must be done on this track. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22597) Exception trace id is not propagated from RAFT listener
[
https://issues.apache.org/jira/browse/IGNITE-22597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861321#comment-17861321
]
Mirza Aliev commented on IGNITE-22597:
--
[~v.pyatkov]
This is from server side (it also will be improved with traceId and code here
https://issues.apache.org/jira/browse/IGNITE-22634)
{noformat}
[2024-07-01T18:39:23,138][WARN
][%isnt_tmpar_0%JRaft-FSMCaller-Disruptor_stripe_0-0][ActionRequestProcessor]
Error occurred on a user's state machine
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleUpdateCommand(PartitionListener.java:277)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:210)
{noformat}
and like this from a client side
{noformat}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:27960e0f-a0e9-4a11-9370-03ab1c7af36e Expected message
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:118)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:138)
...
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:326)
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:283)
at
com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:167)
at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:122)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
IGN-CMN-65535 TraceId:27960e0f-a0e9-4a11-9370-03ab1c7af36e Expected message
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleUpdateCommand(PartitionListener.java:277)
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:210)
... 13 more
Caused by: java.lang.RuntimeException: TEST
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleUpdateCommand(PartitionListener.java:275)
... 14 more
{noformat}
> Exception trace id is not propagated from RAFT listener
> ---
>
> Key: IGNITE-22597
> URL: https://issues.apache.org/jira/browse/IGNITE-22597
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: error_log.txt
>
>
> h3. Motivation
> The trace id is generated at the place where the original exception was
> created and should be propogated to other derevatives. Right now, we send
> only an exception message and class name to the RAFT listener response.
> {code:java}
> private void sendSMError(RpcContext ctx, Throwable th, boolean compacted) {
> RpcRequests.SMErrorResponse resp = factory.sMErrorResponse()
> .error(compacted ? new SMCompactedThrowable(th) : new
> SMFullThrowable(th))
> .build();
> ctx.sendResponse(resp);
> LOG.info("Error occurred on a user's state machine", th);
> }
> {code}
> Hence, we cannot restore the trace id and create an exception with a new
> trace id:
> {code:java}
> Throwable restoredTh = (Throwable)
> Class.forName(compactedThrowable.throwableClassName())
> .getConstructor(String.class)
> .newInstance(compactedThrowable.throwableMessage());
> fut.completeExceptionally(restoredTh);
> {code}
> h3. Definition of done
> * Both attached logs should be logged with the same trace id.
> * Massage in the RAFT listener should be logged in error (or warning) level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
[
https://issues.apache.org/jira/browse/IGNITE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22634:
-
Description:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
*Expected behaviour:*
We see in logs traceId and code of the {{IgniteInternalException}}
*Actual behaviour:*
{code:java}
[2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
{code}
Also it is worth to mention that this behaviour is reproducible in {{log4j2}},
but not in {{JUL}}
was:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
*Expected behaviour:*
We see in logs traceId and code of the {{IgniteInternalException}}
*Actual behaviour:*
{code:java}
[2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
{code}
> IgniteLogger does not print traceId and code for TraceableException
>
>
> Key: IGNITE-22634
> URL: https://issues.apache.org/jira/browse/IGNITE-22634
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png
>
>
> We've noticed that construction like this does not work as we expected:
> {code:java}
> Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
> message");
> log.info("SOME MESSAGE", e);
> log.warn("SOME MESSAGE", e);
> log.error("SOME MESSAGE", e);
> {code}
> *Expected behaviour:*
> We see in logs traceId and code of the {{IgniteInternalException}}
> *Actual behaviour:*
> {code:java}
> [2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> {code}
> Also it is worth to mention that this behaviour is reproducible in
> {{log4j2}}, but not in {{JUL}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
[
https://issues.apache.org/jira/browse/IGNITE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22634:
-
Labels: ignite-3 (was: )
> IgniteLogger does not print traceId and code for TraceableException
>
>
> Key: IGNITE-22634
> URL: https://issues.apache.org/jira/browse/IGNITE-22634
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png
>
>
> We've noticed that construction like this does not work as we expected:
> {code:java}
> Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
> message");
> log.info("SOME MESSAGE", e);
> log.warn("SOME MESSAGE", e);
> log.error("SOME MESSAGE", e);
> {code}
> *Expected behaviour:*
> We see in logs traceId and code of the {{IgniteInternalException}}
> *Actual behaviour:*
> {code:java}
> [2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
[
https://issues.apache.org/jira/browse/IGNITE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22634:
-
Description:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
Expected behaviour:
We see in logs traceId and code of the {{IgniteInternalException}}
Actual behaviour:
{code:java}
[2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
{code}
was:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
Expected behaviour:
We see in logs traceId and code of the {{IgniteInternalException}}
Actual behaviour:
> IgniteLogger does not print traceId and code for TraceableException
>
>
> Key: IGNITE-22634
> URL: https://issues.apache.org/jira/browse/IGNITE-22634
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: screenshot-1.png
>
>
> We've noticed that construction like this does not work as we expected:
> {code:java}
> Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
> message");
> log.info("SOME MESSAGE", e);
> log.warn("SOME MESSAGE", e);
> log.error("SOME MESSAGE", e);
> {code}
> Expected behaviour:
> We see in logs traceId and code of the {{IgniteInternalException}}
> Actual behaviour:
> {code:java}
> [2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
[
https://issues.apache.org/jira/browse/IGNITE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22634:
-
Description:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
*Expected behaviour:*
We see in logs traceId and code of the {{IgniteInternalException}}
*Actual behaviour:*
{code:java}
[2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
{code}
was:
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
Expected behaviour:
We see in logs traceId and code of the {{IgniteInternalException}}
Actual behaviour:
{code:java}
[2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
...
[2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
org.apache.ignite.internal.lang.IgniteInternalException: Expected message
{code}
> IgniteLogger does not print traceId and code for TraceableException
>
>
> Key: IGNITE-22634
> URL: https://issues.apache.org/jira/browse/IGNITE-22634
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: screenshot-1.png
>
>
> We've noticed that construction like this does not work as we expected:
> {code:java}
> Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
> message");
> log.info("SOME MESSAGE", e);
> log.warn("SOME MESSAGE", e);
> log.error("SOME MESSAGE", e);
> {code}
> *Expected behaviour:*
> We see in logs traceId and code of the {{IgniteInternalException}}
> *Actual behaviour:*
> {code:java}
> [2024-07-01T16:35:11,435][INFO ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,445][WARN ][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> ...
> [2024-07-01T16:35:11,446][ERROR][main][CommonsTest] SOME MESSAGE
> org.apache.ignite.internal.lang.IgniteInternalException: Expected message
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
Mirza Aliev created IGNITE-22634:
Summary: IgniteLogger does not print traceId and code for
TraceableException
Key: IGNITE-22634
URL: https://issues.apache.org/jira/browse/IGNITE-22634
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: screenshot-1.png
We've noticed that construction like this does not work as we expected:
{code:java}
Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
message");
log.info("SOME MESSAGE", e);
log.warn("SOME MESSAGE", e);
log.error("SOME MESSAGE", e);
{code}
Expected behaviour:
We see in logs traceId and code of the {{IgniteInternalException}}
Actual behaviour:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22634) IgniteLogger does not print traceId and code for TraceableException
[
https://issues.apache.org/jira/browse/IGNITE-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22634:
-
Attachment: screenshot-1.png
> IgniteLogger does not print traceId and code for TraceableException
>
>
> Key: IGNITE-22634
> URL: https://issues.apache.org/jira/browse/IGNITE-22634
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: screenshot-1.png
>
>
> We've noticed that construction like this does not work as we expected:
> {code:java}
> Throwable e = new IgniteInternalException(INTERNAL_ERR, "Expected
> message");
> log.info("SOME MESSAGE", e);
> log.warn("SOME MESSAGE", e);
> log.error("SOME MESSAGE", e);
> {code}
> Expected behaviour:
> We see in logs traceId and code of the {{IgniteInternalException}}
> Actual behaviour:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22597) Exception trace id is not propagated from RAFT listener
[
https://issues.apache.org/jira/browse/IGNITE-22597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22597:
Assignee: Mirza Aliev
> Exception trace id is not propagated from RAFT listener
> ---
>
> Key: IGNITE-22597
> URL: https://issues.apache.org/jira/browse/IGNITE-22597
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: error_log.txt
>
>
> h3. Motivation
> The trace id is generated at the place where the original exception was
> created and should be propogated to other derevatives. Right now, we send
> only an exception message and class name to the RAFT listener response.
> {code:java}
> private void sendSMError(RpcContext ctx, Throwable th, boolean compacted) {
> RpcRequests.SMErrorResponse resp = factory.sMErrorResponse()
> .error(compacted ? new SMCompactedThrowable(th) : new
> SMFullThrowable(th))
> .build();
> ctx.sendResponse(resp);
> LOG.info("Error occurred on a user's state machine", th);
> }
> {code}
> Hence, we cannot restore the trace id and create an exception with a new
> trace id:
> {code:java}
> Throwable restoredTh = (Throwable)
> Class.forName(compactedThrowable.throwableClassName())
> .getConstructor(String.class)
> .newInstance(compactedThrowable.throwableMessage());
> fut.completeExceptionally(restoredTh);
> {code}
> h3. Definition of done
> * Both attached logs should be logged with the same trace id.
> * Massage in the RAFT listener should be logged in error (or warning) level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22597) Exception trace id is not propagated from RAFT listener
[
https://issues.apache.org/jira/browse/IGNITE-22597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860812#comment-17860812
]
Mirza Aliev commented on IGNITE-22597:
--
[~ktkale...@gridgain.com] could you please clarify, what specifically you want
to be fixed within this ticket?
> Exception trace id is not propagated from RAFT listener
> ---
>
> Key: IGNITE-22597
> URL: https://issues.apache.org/jira/browse/IGNITE-22597
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: error_log.txt
>
>
> h3. Motivation
> The trace id is generated at the place where the original exception was
> created and should be propogated to other derevatives. Right now, we send
> only an exception message and class name to the RAFT listener response.
> {code:java}
> private void sendSMError(RpcContext ctx, Throwable th, boolean compacted) {
> RpcRequests.SMErrorResponse resp = factory.sMErrorResponse()
> .error(compacted ? new SMCompactedThrowable(th) : new
> SMFullThrowable(th))
> .build();
> ctx.sendResponse(resp);
> LOG.info("Error occurred on a user's state machine", th);
> }
> {code}
> Hence, we cannot restore the trace id and create an exception with a new
> trace id:
> {code:java}
> Throwable restoredTh = (Throwable)
> Class.forName(compactedThrowable.throwableClassName())
> .getConstructor(String.class)
> .newInstance(compactedThrowable.throwableMessage());
> fut.completeExceptionally(restoredTh);
> {code}
> h3. Definition of done
> * Both attached logs should be logged with the same trace id.
> * Massage in the RAFT listener should be logged in error (or warning) level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22600) Implement proper way of handling empty stable assignments on zone creation
[ https://issues.apache.org/jira/browse/IGNITE-22600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22600: - Description: TBD > Implement proper way of handling empty stable assignments on zone creation > -- > > Key: IGNITE-22600 > URL: https://issues.apache.org/jira/browse/IGNITE-22600 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22600) Implement proper way of handling empty stable assignments on zone creation
Mirza Aliev created IGNITE-22600: Summary: Implement proper way of handling empty stable assignments on zone creation Key: IGNITE-22600 URL: https://issues.apache.org/jira/browse/IGNITE-22600 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22436) Fix ItReplicaLifecycleTest
[ https://issues.apache.org/jira/browse/IGNITE-22436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22436: - Description: We need to rewrite ItReplicaLifecycleTest so it could be possible to set node attributes to a node when we start it, so we could write proper tests for altering filters as a rebalance trigger. h3. Definition of done * It it possible to pass node attributes to such node was: We need to rewrite ItReplicaLifecycleTest so it could start a node not only in the BeforeEach section, but in any place in a test, also it must be possible to set node attributes to a node, so we could write proper tests for altering filters as a rebalance trigger. h3. Definition of done * It is possible to start a partial node in any place in ItReplicaLifecycleTest * It it possible to pass node attributes to such node > Fix ItReplicaLifecycleTest > -- > > Key: IGNITE-22436 > URL: https://issues.apache.org/jira/browse/IGNITE-22436 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > We need to rewrite ItReplicaLifecycleTest so it could be possible to set node > attributes to a node when we start it, so we could write proper tests for > altering filters as a rebalance trigger. > h3. Definition of done > * It it possible to pass node attributes to such node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22388) Recheck tests from TableManagerTest for correctness
[
https://issues.apache.org/jira/browse/IGNITE-22388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22388:
-
Summary: Recheck tests from TableManagerTest for correctness (was:
TableManagerTest revision)
> Recheck tests from TableManagerTest for correctness
>
>
> Key: IGNITE-22388
> URL: https://issues.apache.org/jira/browse/IGNITE-22388
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
>
> *Description*
> During IGNITE-22315 we found that tests
> {{TableManagerTest#tableManagerStopTest*}} are failed and after
> investigations there was clear that several static mocks aren't in use in
> tests that leads to actually unworked tests. The special case was fixed in
> IGNITE-22355, but there are more issued places, especially described below.
> The main goal of the ticket is to revise the test class and rewrite it in
> accordings to its purpose without any excessive, unused code lines.
> *Motivation*
> There will be provided 3 examples with problematic code the was found in
> {{TableManagerTable#tableManagerStopTest*}} but not limited.
> The first code smell is the name of the tests:
> {{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
> 1st and 4th are different.
> The second is another (except that in IGNITE-22355) static mock
> {{schemaServiceMock}} in try-with-resources block that shouldn't work outside
> the block:
> {code:java}
> private TableViewInternal mockManagersAndCreateTableWithDelay(
> String tableName,
> CompletableFuture tblManagerFut,
> @Nullable Phaser phaser
> ) throws Exception {
> String consistentId = "node0";
> // ...
> when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
> UUID.randomUUID().toString(),
> consistentId,
> new NetworkAddress("localhost", 47500)
> ));
> try (MockedStatic schemaServiceMock =
> mockStatic(SchemaUtils.class)) {
> schemaServiceMock.when(() ->
> SchemaUtils.prepareSchemaDescriptor(any()))
> .thenReturn(mock(SchemaDescriptor.class));
> }
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() ->
> AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
> .thenReturn(assignment);
> }
> //...
> {code}
> In the test class there are only two such mocks and {{affinityServiceMock}}
> is removed in IGNITE-22355, but {{schemaServiceMock}} still requires
> reworking.
> The third issue in the code above: the problem is that {{ts}} isn't really
> uses: {{ts}} is topology service field in the test class, but for
> {{TableManager}} creation topology service arrives from a mocked cluster
> service:
> {code:java}
> private TableManager createTableManager(/*...*/) {
> TableManager tableManager = new TableManager(
> // ...
> clusterService.topologyService(),
> //...
> {code}
> {{topologyService}} is mocked in {{before}} with another mock:
> {code:java}
> @BeforeEach
> void before() throws NodeStoppingException {
> // ...
> TopologyService topologyService = mock(TopologyService.class);
> when(clusterService.topologyService()).thenReturn(topologyService);
> // ...
> {code}
> That means, that {{ts}} field isn't in use and the code above is just for
> nothing.
> There only 3 arguments, but they shows drastical problems with the test class
> and the ticket calls for the class reworking.
> *Definition of done*
> # Tests' names should have meaningful names that differs one from another.
> # Tests shouldn't contain unused and meaningless code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22436) Fix ItReplicaLifecycleTest
[ https://issues.apache.org/jira/browse/IGNITE-22436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-22436: Assignee: Mirza Aliev > Fix ItReplicaLifecycleTest > -- > > Key: IGNITE-22436 > URL: https://issues.apache.org/jira/browse/IGNITE-22436 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > We need to rewrite ItReplicaLifecycleTest so it could start a node not only > in the BeforeEach section, but in any place in a test, also it must be > possible to set node attributes to a node, so we could write proper tests for > altering filters as a rebalance trigger. > h3. Definition of done > * It is possible to start a partial node in any place in > ItReplicaLifecycleTest > * It it possible to pass node attributes to such node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22436) Fix ItReplicaLifecycleTest
Mirza Aliev created IGNITE-22436: Summary: Fix ItReplicaLifecycleTest Key: IGNITE-22436 URL: https://issues.apache.org/jira/browse/IGNITE-22436 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev We need to rewrite ItReplicaLifecycleTest so it could start a node not only in the BeforeEach section, but in any place in a test, also it must be possible to set node attributes to a node, so we could write proper tests for altering filters as a rebalance trigger. h3. Definition of done * It is possible to start a partial node in any place in ItReplicaLifecycleTest * It it possible to pass node attributes to such node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22410) Implement rebalance triggers for zone based partitions
[ https://issues.apache.org/jira/browse/IGNITE-22410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22410: - Description: *Motivation* We need to implement the rebalance routine for zone-based partitions in the new ReplicaLifecycleManager. *Definition of done* - Rebalance keys are placed under the zone.* prefix to separate these keys from the table-based, including in-memory keys - All rebalance triggers are supported - RebalanceRaftGroupEventsListener duplicated for the datareplication module in the scope of zone-based keys also. *Implementation notes* - Zone based keys are already supported in the ignite-collocation-feature and RebalanceUtil/RebalanceRaftGroupEventsListener can be just copied from there to the datareplication module. was: *Motivation* We need to implement the rebalance routine for zone-based partitions in the new ReplicaLifecycleManager. *Definition of done* - Rebalance keys are placed under the zone.* prefix to separate these keys from the table-based. - All rebalance triggers are supported - RebalanceRaftGroupEventsListener duplicated for the datareplication module in the scope of zone-based keys also. *Implementation notes* - Zone based keys are already supported in the ignite-collocation-feature and RebalanceUtil/RebalanceRaftGroupEventsListener can be just copied from there to the datareplication module. > Implement rebalance triggers for zone based partitions > -- > > Key: IGNITE-22410 > URL: https://issues.apache.org/jira/browse/IGNITE-22410 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > > *Motivation* > We need to implement the rebalance routine for zone-based partitions in the > new ReplicaLifecycleManager. > *Definition of done* > - Rebalance keys are placed under the zone.* prefix to separate these keys > from the table-based, including in-memory keys > - All rebalance triggers are supported > - RebalanceRaftGroupEventsListener duplicated for the datareplication module > in the scope of zone-based keys also. > *Implementation notes* > - Zone based keys are already supported in the ignite-collocation-feature and > RebalanceUtil/RebalanceRaftGroupEventsListener can be just copied from there > to the datareplication module. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22374) Support altering partition number for a zone
[ https://issues.apache.org/jira/browse/IGNITE-22374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22374: - Description: This ticket was created mostly to mute some tests after https://issues.apache.org/jira/browse/IGNITE-22275, where we forbade altering partition number for a zone. This ticket can be used as an initial ticket for supporting altering zone partition, but we don't have such plans for the near future because of the complexity of the feature. > Support altering partition number for a zone > > > Key: IGNITE-22374 > URL: https://issues.apache.org/jira/browse/IGNITE-22374 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > This ticket was created mostly to mute some tests after > https://issues.apache.org/jira/browse/IGNITE-22275, where we forbade altering > partition number for a zone. This ticket can be used as an initial ticket for > supporting altering zone partition, but we don't have such plans for the near > future because of the complexity of the feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851555#comment-17851555
]
Mirza Aliev commented on IGNITE-22355:
--
[~jakutenshi] LGTM
> TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay
> don't work properly
> -
>
> Key: IGNITE-22355
> URL: https://issues.apache.org/jira/browse/IGNITE-22355
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Description*
> In tests table creation method there is code like below:
>
> {code:java}
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
> anyInt(), anyInt()))
> .thenReturn(assignment);
> }{code}
> As the result {{AffinityUtils#calculateAssignments}} calls outside of
> try-with-resources returns List of empty sets, but desired behavior is list
> of sets with the given {{{}node{}}}.
> *Definition of done*
> {{AffinityUtils#calculateAssignments}} call inside
> {{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
> with single node.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22207) Handling of AwaitPrimaryReplica request maight lead to the dedalock
[
https://issues.apache.org/jira/browse/IGNITE-22207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22207:
Assignee: Mirza Aliev
> Handling of AwaitPrimaryReplica request maight lead to the dedalock
> ---
>
> Key: IGNITE-22207
> URL: https://issues.apache.org/jira/browse/IGNITE-22207
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We handle ReplicaUnavailableException in ReplicaService to handle request
> transparency even if the replica had not been read at the time the request
> was sent. To do this, we send AwaitReplicaRequest as a handling of the
> exception and then process the origin request when the replica is guaranteed
> ready.
> In the event that the AwaitReplicaRequest is handled locally, we will do it
> synchronously in pendingInvokes.computeIfAbsent:
> {code}
> CompletableFuture awaitReplicaFut =
> pendingInvokes.computeIfAbsent(
> targetNodeConsistentId,
> consistentId -> {
> AwaitReplicaRequest awaitReplicaReq =
> REPLICA_MESSAGES_FACTORY.awaitReplicaRequest()
> .groupId(req.groupId())
> .build();
> return messagingService.invoke(
> targetNodeConsistentId,
> awaitReplicaReq,
> replicationConfiguration.rpcTimeout().value()
> );
> }
> );
> {code}
> and then hands on handling of AwaitReplicaRequest, due to removing from
> pendingInvokes:
> {code}
> awaitReplicaFut.handle((response0, throwable0) -> {
> pendingInvokes.remove(targetNodeConsistentId, awaitReplicaFut);
> ...
> {code}
> h3. Definition of doe
> Take out of the network invokation from the map compute closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22374) Support altering partition number for a zone
Mirza Aliev created IGNITE-22374: Summary: Support altering partition number for a zone Key: IGNITE-22374 URL: https://issues.apache.org/jira/browse/IGNITE-22374 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22305:
-
Epic Link: IGNITE-19170
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22046:
-
Reviewer: Vladislav Pyatkov
> Change API usage of Placement driver in PartitionReplicaListener from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22046
> URL: https://issues.apache.org/jira/browse/IGNITE-22046
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> where PD was used in PartitionReplicaListener and other places connected to
> PartitionReplicaListener that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to PartitionReplicaListener.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}} in
> {{PartitionReplicaListener}} ({{getPrimaryReplica}}, {{awaitPrimaryReplica}})
> must be changed to new methods which use {{ZonePartitionId}} (with tableId).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21913) Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21913:
-
Reviewer: Vladislav Pyatkov
> Change API usage of Placement driver in Transaction module from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21913
> URL: https://issues.apache.org/jira/browse/IGNITE-21913
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in Transaction module where PD was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}, {{awaitPrimaryReplica}}) must be changed to new
> methods which use {{ZonePartitionId}} (with tableId).
> As a side effect, {{PlacementDriver}} events must be changed to
> {{ZonePartitionId}} based events.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22305:
-
Reviewer: (was: Vladislav Pyatkov)
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22305:
-
Reviewer: Vladislav Pyatkov
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22305:
Assignee: Mirza Aliev
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22046:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD
was used in PartitionReplicaListener and other places connected to
PartitionReplicaListener that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to PartitionReplicaListener.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}} in
{{PartitionReplicaListener}} ({{getPrimaryReplica}}, {{awaitPrimaryReplica}})
must be changed to new methods which use {{ZonePartitionId}} (with tableId).
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD
was used in PartitionReplicaListener and other places connected to
PartitionReplicaListener that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to PartitionReplicaListener.
h3. Definition of done
All usages of PlacementDriver API with TablePartitionId in (getPrimaryReplica,
awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId
(with tableId).
> Change API usage of Placement driver in PartitionReplicaListener from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22046
> URL: https://issues.apache.org/jira/browse/IGNITE-22046
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> where PD was used in PartitionReplicaListener and other places connected to
> PartitionReplicaListener that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to PartitionReplicaListener.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}} in
> {{PartitionReplicaListener}} ({{getPrimaryReplica}}, {{awaitPrimaryReplica}})
> must be changed to new methods which use {{ZonePartitionId}} (with tableId).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22046: - Description: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId in (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). was: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. Motivation > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. > h3. Definition of done > All usages of PlacementDriver API with TablePartitionId in > (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which > use ZonePartitionId (with tableId). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22046: - Description: h3. Motivation In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. h3. Definition of done All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId (with tableId). was: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. Motivation > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. > h3. Definition of done > All usages of PlacementDriver API with TablePartitionId (getPrimaryReplica, > awaitPrimaryReplica) must be changed to new methods which use ZonePartitionId > (with tableId). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-22305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22305:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
{{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}} was
used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
ClientPrimaryReplicaTracker where PD.getPrimaryReplica was used before. See
spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with
details about places to change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
> Change API usage of Placement driver for ClientPrimaryReplicaTracker from
> TablePartitionId to ZonePartitionId
> -
>
> Key: IGNITE-22305
> URL: https://issues.apache.org/jira/browse/IGNITE-22305
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for
> {{ClientPrimaryReplicaTracker}} where {{PlacementDriver.getPrimaryReplica}}
> was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> This will be the last place of PD API where {{TablePartitionId}} is used, so
> after that we can get rid of decorator and rename
> {{getPrimaryReplicaForTable}} and {{awaitPrimaryReplicaForTable}} and also we
> can move logic from the decorator to LeaseTracker. Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} could removed.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
> new methods which use {{ZonePartitionId}} (with tableId). Also
> {{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22305) Change API usage of Placement driver for ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
Mirza Aliev created IGNITE-22305:
Summary: Change API usage of Placement driver for
ClientPrimaryReplicaTracker from TablePartitionId to ZonePartitionId
Key: IGNITE-22305
URL: https://issues.apache.org/jira/browse/IGNITE-22305
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for
ClientPrimaryReplicaTracker where PD.getPrimaryReplica was used before. See
spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with
details about places to change.
This will be the last place of PD API where {{TablePartitionId}} is used, so
after that we can get rid of decorator and rename {{getPrimaryReplicaForTable}}
and {{awaitPrimaryReplicaForTable}} and also we can move logic from the
decorator to LeaseTracker. Also {{LeaseTracker#tablePartIdToZoneIdProvider}}
could removed.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}) in {{ClientPrimaryReplicaTracker}} must be changed to
new methods which use {{ZonePartitionId}} (with tableId). Also
{{LeaseTracker#tablePartIdToZoneIdProvider}} must be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21913) Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21913:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
Transaction module where PD was used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
h3. Definition of done
All usages of {{PlacementDriver}} API with {{TablePartitionId}}
({{getPrimaryReplica}}, {{awaitPrimaryReplica}}) must be changed to new methods
which use {{ZonePartitionId}} (with tableId).
As a side effect, {{PlacementDriver}} events must be changed to
{{ZonePartitionId}} based events.
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
Transaction module where PD was used before. See spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to
change.
> Change API usage of Placement driver in Transaction module from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21913
> URL: https://issues.apache.org/jira/browse/IGNITE-21913
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in Transaction module where PD was used before. See spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858 with details about places
> to change.
> h3. Definition of done
> All usages of {{PlacementDriver}} API with {{TablePartitionId}}
> ({{getPrimaryReplica}}, {{awaitPrimaryReplica}}) must be changed to new
> methods which use {{ZonePartitionId}} (with tableId).
> As a side effect, {{PlacementDriver}} events must be changed to
> {{ZonePartitionId}} based events.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22261) Deadlock on configuration application in NodeImpl when disruptors are full
[
https://issues.apache.org/jira/browse/IGNITE-22261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847779#comment-17847779
]
Mirza Aliev commented on IGNITE-22261:
--
The bug is reproducible on the latest {{JRaft}}, I've created the issue in the
{{JRaft}} repo https://github.com/sofastack/sofa-jraft/issues/1105, I would
suggest to discuss this issue with the {{JRaft}} maintainers.
> Deadlock on configuration application in NodeImpl when disruptors are full
> --
>
> Key: IGNITE-22261
> URL: https://issues.apache.org/jira/browse/IGNITE-22261
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls
> LogManager.appendEntries()
> # LogManager tries to enqueue a task to diskQueue which is full, hence it
> blocks until a task gets consumed from diskQueue
> # diskQueue is consumed by StableClosureEventHandler
> # StableClosureEventHandler tries to enqueue a task to
> FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task
> gets consumed from FSMCallerImpl#taskQueue
> # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler
> # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries
> to take NodeImpl#writeLock
> As a result, there is a deadlock:
> NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock
> (disruptors are used as blocking queues in JRaft, so, when full, they act
> like locks).
> This was caught by ItNodeTest#testNodeTaskOverload() which uses extremely
> short disruptors (2 items max each).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22172) Make ignite-collocation-feature branch stable
[ https://issues.apache.org/jira/browse/IGNITE-22172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-22172: - Description: h3. Motivation Too many flaky tests are there. This behavior does not allow us to review a new patch to the branch because TC is permanently red. h3. Definition of done Meke TC green for the ignite-collocation-feature branch. If this point is not acceptable, we need to describe the current issues. was: h3. Motivation Too many flaky tests are there. This behavior does not allow us to review a new patch to the branch because TC is permanently red. h3. Definition of done Meke TC green for the ignite-collocation-feature branch. If this point is not acceptable, we need to describe the current issues. > Make ignite-collocation-feature branch stable > - > > Key: IGNITE-22172 > URL: https://issues.apache.org/jira/browse/IGNITE-22172 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > h3. Motivation > Too many flaky tests are there. This behavior does not allow us to review a > new patch to the branch because TC is permanently red. > h3. Definition of done > Meke TC green for the ignite-collocation-feature branch. > If this point is not acceptable, we need to describe the current issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main
[
https://issues.apache.org/jira/browse/IGNITE-22185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22185:
Assignee: Mirza Aliev
> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
> became flaky on the main
> -
>
> Key: IGNITE-22185
> URL: https://issues.apache.org/jira/browse/IGNITE-22185
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> {{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
> started to fail quite often recently.
> There are two possible errors in the logs:
> {noformat}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
> at
> org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
> {noformat}
> or
> {noformat}
> org.mockito.exceptions.misusing.UnfinishedStubbingException:
> Unfinished stubbing detected here:
> -> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
> {noformat}
> Need to investigate the problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main
Mirza Aliev created IGNITE-22185:
Summary:
DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
became flaky on the main
Key: IGNITE-22185
URL: https://issues.apache.org/jira/browse/IGNITE-22185
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
{{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
started to fail quite often recently.
There are two possible errors in the logs:
{noformat}
java.lang.AssertionError: java.util.concurrent.TimeoutException
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
at
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
at
org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
at
org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
{noformat}
or
{noformat}
org.mockito.exceptions.misusing.UnfinishedStubbingException:
Unfinished stubbing detected here:
-> at
org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
{noformat}
Need to investigate the problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22163) Fix potential NPE in IndexManager
[
https://issues.apache.org/jira/browse/IGNITE-22163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-22163:
Assignee: Mirza Aliev
> Fix potential NPE in IndexManager
> --
>
> Key: IGNITE-22163
> URL: https://issues.apache.org/jira/browse/IGNITE-22163
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> {{org.apache.ignite.internal.index.IndexManager#getMvTableStorage}} could
> produce NPE
> if {{tableAsync}} is not ready
> {code:java}
> CompletableFuture getMvTableStorage(long causalityToken,
> int tableId) {
> return tableManager.tableAsync(causalityToken,
> tableId).thenApply(table -> table.internalTable().storage());
> }
> {code}
> Need to fix this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22163) Fix potential NPE in IndexManager
Mirza Aliev created IGNITE-22163:
Summary: Fix potential NPE in IndexManager
Key: IGNITE-22163
URL: https://issues.apache.org/jira/browse/IGNITE-22163
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
{{org.apache.ignite.internal.index.IndexManager#getMvTableStorage}} could
produce NPE
if {{tableAsync}} is not ready
{code:java}
CompletableFuture getMvTableStorage(long causalityToken,
int tableId) {
return tableManager.tableAsync(causalityToken, tableId).thenApply(table
-> table.internalTable().storage());
}
{code}
Need to fix this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Reviewer: Vladislav Pyatkov
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> where PD was used in {{InternalTableImpl}} and other places connected to
> {{InternalTableImpl}} that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to {{InternalTableImpl}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22122) Fix timeouts for waitForActualStates
Mirza Aliev created IGNITE-22122:
Summary: Fix timeouts for waitForActualStates
Key: IGNITE-22122
URL: https://issues.apache.org/jira/browse/IGNITE-22122
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
There are several places in the code of {{ignite-collocation-feature}} branch,
where timeouts are passed as 1 ms, but they must be justified somehow. This
timeouts are used in {{Replica#waitForActualState}} as an expirationTime for
retrying readIndex command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22119) Fix start of partial nodes from ItIgniteNodeRestartTest and ItIgniteDistributionZoneManagerNodeRestartTest
[
https://issues.apache.org/jira/browse/IGNITE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22119:
-
Description:
h3. Motivation
After https://issues.apache.org/jira/browse/IGNITE-22071 is implemented, there
is a couple of places where we explicitly start components for the test
purposes, so node could start only needed components. In that code, we have
some common pattern like
{code:java}
for (IgniteComponent component : otherComponents) {
component.start();
components.add(component);
} {code}
In the review phase of https://issues.apache.org/jira/browse/IGNITE-22071 it
was proposed to wait here for component to be started.
The problems is that in the common node start you have to call
{{{}metaStorageMgr.notifyRevisionUpdateListenerOnStart(){}}}, so some
components (like {{DistributionZoneManager }}could proceed with its logic,
because it waits for some VersionedValues)
{code:java}
CompletableFuture startupConfigurationUpdate =
notifyConfigurationListeners();
CompletableFuture startupRevisionUpdate =
metaStorageMgr.notifyRevisionUpdateListenerOnStart();
return CompletableFuture.allOf(startupConfigurationUpdate,
startupRevisionUpdate, startFuture) {code}
but in this partial node you wait for node to be started without calling
{{{}notifyRevisionUpdateListenerOnStart{}}}, so it can't start. At lease this
is the root cause for {{{}ItIgniteDistributionZoneManagerNodeRestartTest{}}}. I
bet the problem is the same for {{ItIgniteNodeRestartTest}}
h3. Definition of done
Fix {{ItIgniteNodeRestartTest}} and
{{ItIgniteDistributionZoneManagerNodeRestartTest}} partial node starts, so
async start of components is actually waited.
was:
h3. Motivation
After https://issues.apache.org/jira/browse/IGNITE-22071 is implemented, there
is a couple of places where we explicitly start components for the test
purposes, so node could start only needed components. In that code, we have
some common pattern like
{code:java}
for (IgniteComponent component : otherComponents) {
component.start();
components.add(component);
} {code}
In the review phase of https://issues.apache.org/jira/browse/IGNITE-22071 it
was proposed to wait here for component to be started.
The problems is that in the common node start you have to call
{{{}metaStorageMgr.notifyRevisionUpdateListenerOnStart(){}}}, so some
components (like {{DistributionZoneManager }}could proceed with its logic,
because it waits for some VersionedValues)
{code:java}
CompletableFuture startupConfigurationUpdate =
notifyConfigurationListeners();
CompletableFuture startupRevisionUpdate =
metaStorageMgr.notifyRevisionUpdateListenerOnStart();
return CompletableFuture.allOf(startupConfigurationUpdate,
startupRevisionUpdate, startFuture) {code}
but in this partial node you wait for node to be started without calling
{{{}notifyRevisionUpdateListenerOnStart{}}}, so it can't start. At lease this
is the root cause for {{{}ItIgniteDistributionZoneManagerNodeRestartTest{}}}. I
bet the problem is the same for {{ItIgniteNodeRestartTest}}
h3. Definition of done
Fix ItIgniteNodeRestartTest and ItIgniteDistributionZoneManagerNodeRestartTest
partial node starts, so async start of components is actually waited.
> Fix start of partial nodes from ItIgniteNodeRestartTest and
> ItIgniteDistributionZoneManagerNodeRestartTest
> --
>
> Key: IGNITE-22119
> URL: https://issues.apache.org/jira/browse/IGNITE-22119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> After https://issues.apache.org/jira/browse/IGNITE-22071 is implemented,
> there is a couple of places where we explicitly start components for the test
> purposes, so node could start only needed components. In that code, we have
> some common pattern like
> {code:java}
> for (IgniteComponent component : otherComponents) {
> component.start();
> components.add(component);
> } {code}
> In the review phase of https://issues.apache.org/jira/browse/IGNITE-22071 it
> was proposed to wait here for component to be started.
> The problems is that in the common node start you have to call
> {{{}metaStorageMgr.notifyRevisionUpdateListenerOnStart(){}}}, so some
> components (like {{DistributionZoneManager }}could proceed with its logic,
> because it waits for some VersionedValues)
>
> {code:java}
> CompletableFuture startupConfigurationUpdate =
> notifyConfigurationListeners();
> CompletableFuture startupRevisionUpdate =
> metaStorageMgr.notifyRevisionUpdateListenerOnStart();
> return CompletableFuture.allOf(startupConfigurationUpdate,
> startupRevisionUpdate, sta
[jira] [Created] (IGNITE-22119) Fix start of partial nodes from ItIgniteNodeRestartTest and ItIgniteDistributionZoneManagerNodeRestartTest
Mirza Aliev created IGNITE-22119:
Summary: Fix start of partial nodes from ItIgniteNodeRestartTest
and ItIgniteDistributionZoneManagerNodeRestartTest
Key: IGNITE-22119
URL: https://issues.apache.org/jira/browse/IGNITE-22119
Project: Ignite
Issue Type: Improvement
Reporter: Mirza Aliev
h3. Motivation
After https://issues.apache.org/jira/browse/IGNITE-22071 is implemented, there
is a couple of places where we explicitly start components for the test
purposes, so node could start only needed components. In that code, we have
some common pattern like
{code:java}
for (IgniteComponent component : otherComponents) {
component.start();
components.add(component);
} {code}
In the review phase of https://issues.apache.org/jira/browse/IGNITE-22071 it
was proposed to wait here for component to be started.
The problems is that in the common node start you have to call
{{{}metaStorageMgr.notifyRevisionUpdateListenerOnStart(){}}}, so some
components (like {{DistributionZoneManager }}could proceed with its logic,
because it waits for some VersionedValues)
{code:java}
CompletableFuture startupConfigurationUpdate =
notifyConfigurationListeners();
CompletableFuture startupRevisionUpdate =
metaStorageMgr.notifyRevisionUpdateListenerOnStart();
return CompletableFuture.allOf(startupConfigurationUpdate,
startupRevisionUpdate, startFuture) {code}
but in this partial node you wait for node to be started without calling
{{{}notifyRevisionUpdateListenerOnStart{}}}, so it can't start. At lease this
is the root cause for {{{}ItIgniteDistributionZoneManagerNodeRestartTest{}}}. I
bet the problem is the same for {{ItIgniteNodeRestartTest}}
h3. Definition of done
Fix ItIgniteNodeRestartTest and ItIgniteDistributionZoneManagerNodeRestartTest
partial node starts, so async start of components is actually waited.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
Mirza Aliev created IGNITE-22046: Summary: Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId Key: IGNITE-22046 URL: https://issues.apache.org/jira/browse/IGNITE-22046 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD was used in PartitionReplicaListener and other places connected to PartitionReplicaListener that are described in the spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be propagated to PartitionReplicaListener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-22034:
-
Summary: ItRebalanceTest#testRebalanceTablesCounterForZone is flaky (was:
ItRebalanceTest#testRebalanceTablesCounterForZone is flacky)
> ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
> --
>
> Key: IGNITE-22034
> URL: https://issues.apache.org/jira/browse/IGNITE-22034
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.waitForTablesCounterInMetastore(ItRebalanceTest.java:261)
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.testRebalanceTablesCounterForZone(ItRebalanceTest.java:199)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> The reason of this NPE is {{lastAssignmentsHolderForLog[0]}} equals {{null}}.
> We have not wait of appier a key in the metastorage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver with a ned
method, which will accept ZonePartitionId with tableId and will force primary
replica to wait for it state to be in sync with a leader state if lease for
ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Aforementioned Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver with a ned
method, which will accept ZonePartitionId with tableId and will force primary
replica to wait for it state to be in sync with a leader state if lease for
ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver with a ned
> method, which will accept ZonePartitionId with tableId and will force primary
> replica to wait for it state to be in sync with a leader state if lease for
> ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
> h3. Definition of done
> * Aforementioned Decorator for Placement Driver is created
> * Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
> used must be changed to a new method from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver with a ned
method, which will accept ZonePartitionId with tableId and will force primary
replica to wait for it state to be in sync with a leader state if lease for
ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver with a ned
method, which will accept ZonePartitionId with tableId and will force primary
replica to wait for it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver with a ned
> method, which will accept ZonePartitionId with tableId and will force primary
> replica to wait for it state to be in sync with a leader state if lease for
> ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
> h3. Definition of done
> * Decorator for Placement Driver is created
> * Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
> used must be changed to a new method from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to new method from the decorator
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver, which
> will accept ZonePartitionId with tableId and will force primary replica to
> wait for it state event if lease for ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
> h3. Definition of done
> * Decorator for Placement Driver is created
> * Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
> used must be changed to new method from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver with a ned
method, which will accept ZonePartitionId with tableId and will force primary
replica to wait for it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver with a ned
> method, which will accept ZonePartitionId with tableId and will force primary
> replica to wait for it state event if lease for ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
> h3. Definition of done
> * Decorator for Placement Driver is created
> * Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
> used must be changed to a new method from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to a new method from the decorator
was:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
h3. Definition of done
* Decorator for Placement Driver is created
* Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
used must be changed to new method from the decorator
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver, which
> will accept ZonePartitionId with tableId and will force primary replica to
> wait for it state event if lease for ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
> h3. Definition of done
> * Decorator for Placement Driver is created
> * Places in index module where {{PlacementDriver#awaitPrimaryReplica}} where
> used must be changed to a new method from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834838#comment-17834838
]
Mirza Aliev edited comment on IGNITE-21859 at 4/8/24 8:21 AM:
--
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase and default zone
descriptor doesn't have correct {{CatalogObjectDescriptor#updateToken()}}. I
expect this bug is being fixed in the default zone refactoring epic
automatically because the initialisation of the default zone will be changed
https://issues.apache.org/jira/browse/IGNITE-20613
was (Author: maliev):
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase and default zone
descriptor doesn't have correct {{CatalogObjectDescriptor#updateToken()}}. I
expect this bug is being fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834838#comment-17834838
]
Mirza Aliev edited comment on IGNITE-21859 at 4/8/24 8:19 AM:
--
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase and default zone
descriptor doesn't have correct {{CatalogObjectDescriptor#updateToken()}}. I
expect this bug is being fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
was (Author: maliev):
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase and default zone
descriptor doesn't have correct {{CatalogObjectDescriptor#updateToken()}}. I
expect this bug is fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834838#comment-17834838
]
Mirza Aliev edited comment on IGNITE-21859 at 4/8/24 8:18 AM:
--
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase and default zone
descriptor doesn't have correct {{CatalogObjectDescriptor#updateToken()}}. I
expect this bug is fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
was (Author: maliev):
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase. I expect this bug is
fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21859:
-
Epic Link: IGNITE-20613
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834838#comment-17834838
]
Mirza Aliev commented on IGNITE-21859:
--
The root cause of this problem is the way how the default zone is created. It
is just injected to the Catalog constructor and is not created through the
common flow of Catalog entity creation, hence Catalog with this default zone is
not saved in the meta storage on the initialisation phase. I expect this bug is
fixed in the default zone refactoring epic
https://issues.apache.org/jira/browse/IGNITE-20613
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places where PD
was used in {{InternalTableImpl}} and other places connected to
{{InternalTableImpl}} that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to {{InternalTableImpl}}.
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places connected to {{InternalTableImpl}} that
are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to {{InternalTableImpl}}.
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> where PD was used in {{InternalTableImpl}} and other places connected to
> {{InternalTableImpl}} that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to {{InternalTableImpl}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21913) Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21913: - Description: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in Transaction module where PD was used before. See spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to change. was: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in Transaction module. See spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to change. > Change API usage of Placement driver in Transaction module from > TablePartitionId to ZonePartitionId > --- > > Key: IGNITE-21913 > URL: https://issues.apache.org/jira/browse/IGNITE-21913 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > in Transaction module where PD was used before. See spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858 with details about places > to change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21913) Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId
Mirza Aliev created IGNITE-21913: Summary: Change API usage of Placement driver in Transaction module from TablePartitionId to ZonePartitionId Key: IGNITE-21913 URL: https://issues.apache.org/jira/browse/IGNITE-21913 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in Transaction module. See spreadsheet from https://issues.apache.org/jira/browse/IGNITE-21858 with details about places to change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places connected to {{InternalTableImpl}} that
are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to {{InternalTableImpl}}.
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to {{InternalTableImpl}}
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in {{InternalTableImpl}} and other places connected to {{InternalTableImpl}}
> that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to {{InternalTableImpl}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and
org.apache.ignite.internal.index.IndexBuildController where old PD API where
used must be changed to new methods from the decorator
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and
org.apache.ignite.internal.index.IndexBuildController where old PD API where
used must be changed to new methods from the decorator
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in {{InternalTableImpl}} and other places according connected to
> {{InternalTableImpl}} that are described in the spreadsheet from
> Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and
> org.apache.ignite.internal.index.IndexBuildController where old PD API where
> used must be changed to new methods from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
propagated to {{InternalTableImpl}}
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in {{InternalTableImpl}} and other places according connected to
> {{InternalTableImpl}} that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be
> propagated to {{InternalTableImpl}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21912:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
https://issues.apache.org/jira/browse/IGNITE-21858
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to use previously created decorator for Placement Driver
from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in
{{InternalTableImpl}} and other places according connected to
{{InternalTableImpl}} that are described in the spreadsheet from
Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and
org.apache.ignite.internal.index.IndexBuildController where old PD API where
used must be changed to new methods from the decorator
> Change API usage of Placement driver for InternalTableImpl interaction from
> TablePartitionId to ZonePartitionId
> ---
>
> Key: IGNITE-21912
> URL: https://issues.apache.org/jira/browse/IGNITE-21912
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to use previously created decorator for Placement
> Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places
> in {{InternalTableImpl}} and other places according connected to
> {{InternalTableImpl}} that are described in the spreadsheet from
> https://issues.apache.org/jira/browse/IGNITE-21858
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21912: - Description: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to use previously created decorator for Placement Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places in Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and org.apache.ignite.internal.index.IndexBuildController where old PD API where used must be changed to new methods from the decorator > Change API usage of Placement driver for InternalTableImpl interaction from > TablePartitionId to ZonePartitionId > --- > > Key: IGNITE-21912 > URL: https://issues.apache.org/jira/browse/IGNITE-21912 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > in > Also all places in org.apache.ignite.internal.index.ChangeIndexStatusTask and > org.apache.ignite.internal.index.IndexBuildController where old PD API where > used must be changed to new methods from the decorator -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21912: - Labels: ignite-3 (was: ) > Change API usage of Placement driver for InternalTableImpl interaction from > TablePartitionId to ZonePartitionId > --- > > Key: IGNITE-21912 > URL: https://issues.apache.org/jira/browse/IGNITE-21912 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-21912: Assignee: Mirza Aliev > Change API usage of Placement driver for InternalTableImpl interaction from > TablePartitionId to ZonePartitionId > --- > > Key: IGNITE-21912 > URL: https://issues.apache.org/jira/browse/IGNITE-21912 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21912) Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId
Mirza Aliev created IGNITE-21912: Summary: Change API usage of Placement driver for InternalTableImpl interaction from TablePartitionId to ZonePartitionId Key: IGNITE-21912 URL: https://issues.apache.org/jira/browse/IGNITE-21912 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[
https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21911:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept ZonePartitionId with tableId and will force primary replica to wait for
it state event if lease for ZonePartitionId is accepted.
Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD API
where used must be changed to new methods from the decorator
was:
In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
decompose original task to several subtasks.
In this ticket we need to provide a decorator for Placement Driver, which will
accept
> Change API usage of Placement driver in Index module from TablePartitionId to
> ZonePartitionId
> -
>
> Key: IGNITE-21911
> URL: https://issues.apache.org/jira/browse/IGNITE-21911
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to
> decompose original task to several subtasks.
> In this ticket we need to provide a decorator for Placement Driver, which
> will accept ZonePartitionId with tableId and will force primary replica to
> wait for it state event if lease for ZonePartitionId is accepted.
> Also all places in {{org.apache.ignite.internal.index.ChangeIndexStatusTask}}
> and {{org.apache.ignite.internal.index.IndexBuildController}} where old PD
> API where used must be changed to new methods from the decorator
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21911: - Description: In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to decompose original task to several subtasks. In this ticket we need to provide a decorator for Placement Driver, which will accept > Change API usage of Placement driver in Index module from TablePartitionId to > ZonePartitionId > - > > Key: IGNITE-21911 > URL: https://issues.apache.org/jira/browse/IGNITE-21911 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to provide a decorator for Placement Driver, which > will accept -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21911) Change API usage of Placement driver in Index module from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-21911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-21911: Assignee: Mirza Aliev > Change API usage of Placement driver in Index module from TablePartitionId to > ZonePartitionId > - > > Key: IGNITE-21911 > URL: https://issues.apache.org/jira/browse/IGNITE-21911 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
