[jira] [Resolved] (IGNITE-22038) Error while sending partition idle safe time request breaks sending for all replicas
[ https://issues.apache.org/jira/browse/IGNITE-22038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-22038. -- Resolution: Fixed > Error while sending partition idle safe time request breaks sending for all > replicas > > > Key: IGNITE-22038 > URL: https://issues.apache.org/jira/browse/IGNITE-22038 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > This happens because if a runnable passed to > ScheduledExecutor#scheduleAtFixedRate() throws an exception, tasks stop being > executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22038) Error while sending partition idle safe time request breaks sending for all replicas
[ https://issues.apache.org/jira/browse/IGNITE-22038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22038: --- Description: This happens because if a runnable passed to ScheduledExecutor#scheduleAtFixedRate() throws an exception, tasks stop being executed. > Error while sending partition idle safe time request breaks sending for all > replicas > > > Key: IGNITE-22038 > URL: https://issues.apache.org/jira/browse/IGNITE-22038 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > This happens because if a runnable passed to > ScheduledExecutor#scheduleAtFixedRate() throws an exception, tasks stop being > executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22038) Error while sending partition idle safe time request breaks sending for all replicas
Roman Puchkovskiy created IGNITE-22038: -- Summary: Error while sending partition idle safe time request breaks sending for all replicas Key: IGNITE-22038 URL: https://issues.apache.org/jira/browse/IGNITE-22038 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22024) ItSqlClientSynchronousApiTest#runtimeErrorInDmlCausesTransactionToFail is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22024:
-
Epic Link: IGNITE-21389
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItSqlClientSynchronousApiTest#runtimeErrorInDmlCausesTransactionToFail is
> flaky
> ---
>
> Key: IGNITE-22024
> URL: https://issues.apache.org/jira/browse/IGNITE-22024
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png
>
>
> h3. Motivation
> Only one commit is a base transaction guarantee. The test shows this
> guarantee is violated for thin clients.
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
>
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCode(IgniteTestUtils.java:314)
> at
> org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.runtimeErrorInDmlCausesTransactionToFail(ItSqlApiBaseTest.java:648)
> at
> org.apache.ignite.internal.sql.api.ItSqlClientSynchronousApiTest.runtimeErrorInDmlCausesTransactionToFail(ItSqlClientSynchronousApiTest.java:65)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> h3. Definition of done
> Any transaction operation must
[jira] [Created] (IGNITE-22037) AI3 3rd party dependencies checker
Mikhail Pochatkin created IGNITE-22037: -- Summary: AI3 3rd party dependencies checker Key: IGNITE-22037 URL: https://issues.apache.org/jira/browse/IGNITE-22037 Project: Ignite Issue Type: Improvement Components: build Reporter: Mikhail Pochatkin Currently we have approved list of 3rd party dependencies for runtime/test code scopes. [https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide] So, we need to create some protection from adding new unapproved dependecies, at least for runtime dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20516) Remove openapi.yaml spec from git repository
[ https://issues.apache.org/jira/browse/IGNITE-20516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836627#comment-17836627 ] Mikhail Pochatkin commented on IGNITE-20516: TC task [--> Run :: All Tests / #30340 at 12 Apr 12:42 — TeamCity (apache.org)|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Release_Build_9OpenAPISpecification#all-projects] > Remove openapi.yaml spec from git repository > > > Key: IGNITE-20516 > URL: https://issues.apache.org/jira/browse/IGNITE-20516 > Project: Ignite > Issue Type: Task > Components: rest >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Source of truth for rest api should be java code. So, generated openapi spec > should not be saved in repo (modules/rest-api/openapi/openapi.yaml) > spec should be provided as artifact in TC -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22005) 'Failed to process replica request' error under load with balance transfer scenario
[
https://issues.apache.org/jira/browse/IGNITE-22005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836619#comment-17836619
]
Alexander Lapin commented on IGNITE-22005:
--
Postponed, not enough capacity.
> 'Failed to process replica request' error under load with balance transfer
> scenario
> ---
>
> Key: IGNITE-22005
> URL: https://issues.apache.org/jira/browse/IGNITE-22005
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
> Environment: Cluster of 3 nodes
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
> Attachments: transfer_ign3.yaml
>
>
> *Steps to reproduce:*
> Perform a long (about 2 hours) load test with a balance transfer scenario
> (see scenario pseudo code in attachments).
> *Expected result:*
> No errors happen.
> *Actual result:*
> Get error in server logs - {{Failed to process replica request}}
> {code:java}
> 2024-04-05 17:50:55:802 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%JRaft-AppendEntries-Processor-2][NodeImpl]
> Node <193_part_15/poc-tester-SERVER-192.168.1.97-id-0> is not in active
> state, currTerm=2.
> 2024-04-05 17:50:55:805 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%Raft-Group-Client-19][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=0,
> enlistmentConsistencyToken=112218720633356321, groupId=123_part_21,
> groups=HashMap {141_part_13=poc-tester-SERVER-192.168.1.27-id-0,
> 139_part_9=poc-tester-SERVER-192.168.1.97-id-0,
> 193_part_3=poc-tester-SERVER-192.168.1.27-id-0,
> 19_part_23=poc-tester-SERVER-192.168.1.27-id-0,
> 117_part_17=poc-tester-SERVER-192.168.1.18-id-0,
> 45_part_9=poc-tester-SERVER-192.168.1.18-id-0,
> 39_part_3=poc-tester-SERVER-192.168.1.18-id-0,
> 77_part_4=poc-tester-SERVER-192.168.1.18-id-0,
> 105_part_4=poc-tester-SERVER-192.168.1.18-id-0,
> 123_part_21=poc-tester-SERVER-192.168.1.97-id-0,
> 103_part_9=poc-tester-SERVER-192.168.1.18-id-0,
> 161_part_15=poc-tester-SERVER-192.168.1.27-id-0,
> 103_part_22=poc-tester-SERVER-192.168.1.27-id-0,
> 89_part_10=poc-tester-SERVER-192.168.1.18-id-0,
> 39_part_19=poc-tester-SERVER-192.168.1.27-id-0,
> 149_part_13=poc-tester-SERVER-192.168.1.27-id-0,
> 97_part_24=poc-tester-SERVER-192.168.1.97-id-0,
> 83_part_9=poc-tester-SERVER-192.168.1.27-id-0,
> 209_part_10=poc-tester-SERVER-192.168.1.27-id-0,
> 185_part_5=poc-tester-SERVER-192.168.1.18-id-0,
> 117_part_9=poc-tester-SERVER-192.168.1.27-id-0,
> 105_part_22=poc-tester-SERVER-192.168.1.18-id-0},
> timestampLong=112219170129903617, txId=018eaebd-88ba-0001-606d-62250001]].
> java.util.concurrent.CompletionException:
> org.apache.ignite.tx.TransactionException: IGN-TX-7
> TraceId:cb1577e6-ec35-47f0-ab7d-56a0687344ed
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:932)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$applyCmdWithRetryOnSafeTimeReorderException$126(PartitionReplicaListener.java:2806)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
> 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
>
[jira] [Assigned] (IGNITE-21976) Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax
[ https://issues.apache.org/jira/browse/IGNITE-21976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21976: - Assignee: Pavel Pereslegin > Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax > - > > Key: IGNITE-21976 > URL: https://issues.apache.org/jira/browse/IGNITE-21976 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > After IGNITE-21353 we can use syntax to choose the type of PK index as SORTED > or HASH, but we still have different keywords for CREATE INDEX syntax where > we should use TREE or HASH types. Let's have the same keyword for the sorted > index. > So, required to rename TREE to SORTED for CREATE INDEX syntax -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22006) 'Failed to process the lease granted message' error under load with balance transfer scenario
[
https://issues.apache.org/jira/browse/IGNITE-22006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836618#comment-17836618
]
Alexander Lapin commented on IGNITE-22006:
--
Postponed, not enough capacity.
> 'Failed to process the lease granted message' error under load with balance
> transfer scenario
> -
>
> Key: IGNITE-22006
> URL: https://issues.apache.org/jira/browse/IGNITE-22006
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
> Environment: Cluster of 3 nodes
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
> Attachments: transfer_ign3.yaml
>
>
> *Steps to reproduce:*
> Perform a long (about 2 hours) load test with a balance transfer scenario
> (see scenario pseudo code in attachments).
> *Expected result:*
> No errors happen.
> *Actual result:*
> Get error in server logs - {{Failed to process the lease granted message}}
> {code:java}
> 2024-04-05 17:50:39:180 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%JRaft-Request-Processor-13][NodeImpl]
> Node <127_part_16/poc-tester-SERVER-192.168.1.97-id-0> is not in active
> state, currTerm=3.
> 2024-04-05 17:50:39:187 +0300
> [WARNING][CompletableFutureDelayScheduler][ReplicaManager] Failed to process
> the lease granted message [msg=LeaseGrantedMessageImpl [force=true,
> groupId=77_part_14, leaseExpirationTimeLong=112219169697759232,
> leaseStartTimeLong=112219161833439373]].
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> 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)
> 2024-04-05 17:50:39:190 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%JRaft-Request-Processor-34][NodeImpl]
> Node <213_part_14/poc-tester-SERVER-192.168.1.97-id-0> is not in active
> state, currTerm=2.{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22004) 'Failed to process delayed response' error under load with balance transfer scenario
[
https://issues.apache.org/jira/browse/IGNITE-22004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836617#comment-17836617
]
Alexander Lapin commented on IGNITE-22004:
--
Postponed, not enough capacity.
> 'Failed to process delayed response' error under load with balance transfer
> scenario
>
>
> Key: IGNITE-22004
> URL: https://issues.apache.org/jira/browse/IGNITE-22004
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
> Environment: Cluster of 3 nodes
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
> Attachments: transfer_ign3.yaml
>
>
> *Steps to reproduce:*
> Perform a long (about 2 hours) load test with a balance transfer scenario
> (see scenario pseudo code in attachments).
> *Expected result:*
> No errors happen.
> *Actual result:*
> Get error in server logs - {{Failed to process delayed response}}
> {code:java}
> 2024-04-05 17:50:50:776 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%JRaft-Request-Processor-1][NodeImpl]
> Node <27_part_23/poc-tester-SERVER-192.168.1.97-id-0> is not in active
> state, currTerm=2.
> 2024-04-05 17:50:50:778 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%Raft-Group-Client-5][ReplicaManager]
> Failed to process delayed response
> [request=ReadWriteSingleRowReplicaRequestImpl
> [commitPartitionId=TablePartitionIdMessageImpl [partitionId=21, tableId=123],
> coordinatorId=3de6f999-7ab9-4405-aff0-ee0c7e4886ce,
> enlistmentConsistencyToken=112218720633356321, full=false,
> groupId=123_part_21, requestType=RW_UPSERT, schemaVersion=1,
> timestampLong=112219169796915211,
> transactionId=018eaebd-88ba-0001-606d-62250001]]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
> 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)
> Caused by: java.util.concurrent.TimeoutException
> ... 8 more
> 2024-04-05 17:50:50:780 +0300
> [WARNING][%poc-tester-SERVER-192.168.1.97-id-0%JRaft-Request-Processor-27][NodeImpl]
> Node <99_part_6/poc-tester-SERVER-192.168.1.97-id-0> is not in active state,
> currTerm=3. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22036: Labels: ignite-3 (was: ) > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22036: Epic Link: IGNITE-19170 > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22036: Description: *Motivation* To simplify the process of moving to the zone-based collocation we need to remove all raft-connected code from TableManager. After IGNITE-21805 we will still have: * TableManager.changePeersOnRebalance This method must be replaced by appropriate request to Replica. *Definition of done* * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct call to raft changePeersAsync *Implementation details* We need to: * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - the new replica request type * Move the code from TableManager.changePeersOnRebalance to the Replica itself, as a reaction to ChangePeersReplicaRequest * TableManager must send the ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct TableManager.changePeersOnRebalance call was: *Motivation* To simplify the process of moving to the zone-based collocation we need to remove all raft-connected code from TableManager. After IGNITE-21805 we will still have: - TableManager.changePeersOnRebalance This method must be replaced by appropriate request to Replica. Definition of done - TableManager send the broadcast ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct call to raft changePeersAsync Implementation details: We need to: - Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - the new replica request type - Move the code from TableManager.changePeersOnRebalance to the Replica itself, as a reaction to ChangePeersReplicaRequest - TableManager must send the ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct TableManager.changePeersOnRebalance call > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22036: Description: *Motivation* To simplify the process of moving to the zone-based collocation we need to remove all raft-connected code from TableManager. After IGNITE-21805 we will still have: - TableManager.changePeersOnRebalance This method must be replaced by appropriate request to Replica. Definition of done - TableManager send the broadcast ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct call to raft changePeersAsync Implementation details: We need to: - Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - the new replica request type - Move the code from TableManager.changePeersOnRebalance to the Replica itself, as a reaction to ChangePeersReplicaRequest - TableManager must send the ChangePeersReplicaRequest to all nodes from table partition assignments instead of direct TableManager.changePeersOnRebalance call > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > - TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > Definition of done > - TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > Implementation details: > We need to: > - Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > - Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > - TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
Kirill Gusakov created IGNITE-22036: --- Summary: Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest Key: IGNITE-22036 URL: https://issues.apache.org/jira/browse/IGNITE-22036 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- 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] [Commented] (IGNITE-21826) MvccCoordinator removal
[ https://issues.apache.org/jira/browse/IGNITE-21826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836583#comment-17836583 ] Julia Bakulina commented on IGNITE-21826: - [~oleg_vlsk] could I proceed with this ticket? > MvccCoordinator removal > --- > > Key: IGNITE-21826 > URL: https://issues.apache.org/jira/browse/IGNITE-21826 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > > MvccCoordinator class and corresponding code have to be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22035) Integration tests consume a lot of RAM
[ https://issues.apache.org/jira/browse/IGNITE-22035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836564#comment-17836564 ] Mikhail Pochatkin commented on IGNITE-22035: LGTM! Thanks Merged to main: f38ecb94b7f1ce447de332082773e1d1c05d0fad > Integration tests consume a lot of RAM > -- > > Key: IGNITE-22035 > URL: https://issues.apache.org/jira/browse/IGNITE-22035 > Project: Ignite > Issue Type: Bug >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > In the IGNITE-21594 the test node configuration was updated but the default > storage profile remained with the default configuration which consumes a lot > of RAM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836562#comment-17836562
]
Ignite TC Bot commented on IGNITE-22026:
{panel:title=Branch: [pull/11311/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11311/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=7821181]]
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=0] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=1] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=0] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=3] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=10] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=1] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSendOrdered[retryCnt=3] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
GridCacheIoManagerRetryTest.testSend[retryCnt=10] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7821279buildTypeId=IgniteTests24Java8_RunAll]
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836563#comment-17836563
]
Ilya Shishkov commented on IGNITE-22026:
[~timonin.maksim], can you take a look, please?
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21746) Sql. Change default type of primary key index from hash to sorted.
[ https://issues.apache.org/jira/browse/IGNITE-21746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836556#comment-17836556 ] Iurii Gerzhedovich commented on IGNITE-21746: - Right now benchmarks show 10% performance drop with the patch. Let's increase the performance of SORTED indexes before applying the change. > Sql. Change default type of primary key index from hash to sorted. > -- > > Key: IGNITE-21746 > URL: https://issues.apache.org/jira/browse/IGNITE-21746 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Let's change type of a primary key index from hash to sorted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22035) Integration tests consume a lot of RAM
Vadim Pakhnushev created IGNITE-22035: - Summary: Integration tests consume a lot of RAM Key: IGNITE-22035 URL: https://issues.apache.org/jira/browse/IGNITE-22035 Project: Ignite Issue Type: Bug Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev In the IGNITE-21594 the test node configuration was updated but the default storage profile remained with the default configuration which consumes a lot of RAM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21963) flaky KvMarshallerTest#basicTypes
[
https://issues.apache.org/jira/browse/IGNITE-21963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21963:
-
Assignee: Maksim Zhuravkov
> flaky KvMarshallerTest#basicTypes
> -
>
> Key: IGNITE-21963
> URL: https://issues.apache.org/jira/browse/IGNITE-21963
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> The test
> org.apache.ignite.internal.schema.marshaller.KvMarshallerTest#basicTypes is
> flaky on TC
> ([link|https://ci.ignite.apache.org/test/8717516430421609050?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual=true])
>
> Locally it is also reproducible, just run it until failure mode.
> {code:java}
> org.apache.ignite.internal.marshaller.MarshallerException: IGN-CMN-65535
> TraceId:40e8232a-643d-4753-9916-9b900e6e21fa Offset entry overflow in binary
> tuple builder at
> org.apache.ignite.internal.schema.marshaller.MarshallerForSchema_1800.marshal(Unknown
> Source)
> at
> org.apache.ignite.internal.schema.marshaller.KvMarshallerTest.checkBasicType(KvMarshallerTest.java:731)
> at
> org.apache.ignite.internal.schema.marshaller.KvMarshallerTest.lambda$basicTypes$8(KvMarshallerTest.java:162)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992)
> at
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:735)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEachOrdered(ReferencePipeline.java:601)
> at java.base/java.util.Optional.ifPresent(Optional.java:178)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Caused by: java.lang.IllegalStateException: Offset entry overflow in binary
> tuple builder
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleBuilder.buildInternal(BinaryTupleBuilder.java:653)
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleBuilder.build(BinaryTupleBuilder.java:640)
> at
> org.apache.ignite.internal.schema.row.RowAssembler.build(RowAssembler.java:598)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-22032:
-
Assignee: (was: Maksim Zhuravkov)
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-22032:
-
Assignee: Maksim Zhuravkov
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22020) DumpReder misses 'keepRaw' parameter
[
https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836510#comment-17836510
]
Ignite TC Bot commented on IGNITE-22020:
{panel:title=Branch: [pull/11309/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11309/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots 3{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7821394]]
* {color:#013220}IgniteSnapshotTestSuite3:
IgniteCacheDumpSelf2Test.testDumpRawData - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7821395buildTypeId=IgniteTests24Java8_RunAll]
> DumpReder misses 'keepRaw' parameter
>
>
> Key: IGNITE-22020
> URL: https://issues.apache.org/jira/browse/IGNITE-22020
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only
> `keepBinary` is available. It makes impossible to read data as
> `KeyCacheObject` or `CacheObject` .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-22034:
---
Description:
{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.
was:
{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}
> ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
> ---
>
> 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-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-22034:
---
Description:
{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}
was:
{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)
{nofomrat}
> ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
> ---
>
> 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}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-22034:
---
Description:
{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)
{nofomrat}
> ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
> ---
>
> 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)
> {nofomrat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flacky
Vladislav Pyatkov created IGNITE-22034: -- Summary: ItRebalanceTest#testRebalanceTablesCounterForZone is flacky Key: IGNITE-22034 URL: https://issues.apache.org/jira/browse/IGNITE-22034 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22033) Replace PlacementDriver#currentLease with #getPrimaryReplica in ReadWriteTxContext#waitReadyToFinish
[
https://issues.apache.org/jira/browse/IGNITE-22033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22033:
--
Attachment: _Integration_Tests_Module_Runner_24658_.log
> Replace PlacementDriver#currentLease with #getPrimaryReplica in
> ReadWriteTxContext#waitReadyToFinish
>
>
> Key: IGNITE-22033
> URL: https://issues.apache.org/jira/browse/IGNITE-22033
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_24658_.log
>
>
> #currentLease can return null in a case when there is no lease information on
> the current node yet, while the lease may already exist on another node. This
> can lead to
> PrimaryReplicaExpiredException.
> Seems that we've already seen such exceptions on TC:
>
> {code:java}
> Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
> IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
> expired, transaction will be rolled back: [groupId = 59_part_11, expected
> enlistment consistency token = 112211838526816298, commit timestamp = null,
> current primary replica = null]
> at
> app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
> at
> app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
> at
> app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
> at
> app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finishInternal(ReadWriteTransactionImpl.java:161)
> at
> app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finish(ReadWriteTransactionImpl.java:140)
> at
> app//org.apache.ignite.internal.tx.impl.IgniteAbstractTransactionImpl.commitAsync(IgniteAbstractTransactionImpl.java:98)
> at
> app//org.apache.ignite.internal.sql.engine.tx.QueryTransactionWrapperImpl.commitImplicit(QueryTransactionWrapperImpl.java:46)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$closeAsync$3(AsyncSqlCursorImpl.java:132)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.closeAsync(AsyncSqlCursorImpl.java:132)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:101)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.requestNextAsync(AsyncSqlCursorImpl.java:94)
> at
> app//org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$4(IgniteSqlImpl.java:360)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> app//org.apache.ignite.internal.sql.engine.SqlQueryProcessor$PrefetchCallback.onPrefetchComplete(SqlQueryProcessor.java:1050)
> at
> app//org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$3(KeyValueModifyPlan.java:141)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
> at
> app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83){code}
> Full log attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22033) Replace PlacementDriver#currentLease with #getPrimaryReplica in ReadWriteTxContext#waitReadyToFinish
[
https://issues.apache.org/jira/browse/IGNITE-22033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22033:
--
Description:
#currentLease can return null in a case when there is no lease information on
the current node yet, while the lease may already exist on another node. This
can lead to
PrimaryReplicaExpiredException.
Seems that we've already seen such exceptions on TC:
{code:java}
Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
expired, transaction will be rolled back: [groupId = 59_part_11, expected
enlistment consistency token = 112211838526816298, commit timestamp = null,
current primary replica = null]
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
at
app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finishInternal(ReadWriteTransactionImpl.java:161)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finish(ReadWriteTransactionImpl.java:140)
at
app//org.apache.ignite.internal.tx.impl.IgniteAbstractTransactionImpl.commitAsync(IgniteAbstractTransactionImpl.java:98)
at
app//org.apache.ignite.internal.sql.engine.tx.QueryTransactionWrapperImpl.commitImplicit(QueryTransactionWrapperImpl.java:46)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$closeAsync$3(AsyncSqlCursorImpl.java:132)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.closeAsync(AsyncSqlCursorImpl.java:132)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:101)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.requestNextAsync(AsyncSqlCursorImpl.java:94)
at
app//org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$4(IgniteSqlImpl.java:360)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
app//org.apache.ignite.internal.sql.engine.SqlQueryProcessor$PrefetchCallback.onPrefetchComplete(SqlQueryProcessor.java:1050)
at
app//org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$3(KeyValueModifyPlan.java:141)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
at
app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83){code}
was:
#currentLease can return null in a case when there is no lease information on
the current node yet, while the lease may already exist on another node. This
can lead to
PrimaryReplicaExpiredException.
Seems that we've already seen such exceptions on TC:
{code:java}
Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
expired, transaction will be rolled back: [groupId = 59_part_11, expected
enlistment consistency token = 112211838526816298, commit timestamp = null,
current primary replica = null] at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
at
app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
at
[jira] [Updated] (IGNITE-22033) Replace PlacementDriver#currentLease with #getPrimaryReplica in ReadWriteTxContext#waitReadyToFinish
[
https://issues.apache.org/jira/browse/IGNITE-22033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22033:
--
Description:
#currentLease can return null in a case when there is no lease information on
the current node yet, while the lease may already exist on another node. This
can lead to
PrimaryReplicaExpiredException.
Seems that we've already seen such exceptions on TC:
{code:java}
Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
expired, transaction will be rolled back: [groupId = 59_part_11, expected
enlistment consistency token = 112211838526816298, commit timestamp = null,
current primary replica = null]
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
at
app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finishInternal(ReadWriteTransactionImpl.java:161)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finish(ReadWriteTransactionImpl.java:140)
at
app//org.apache.ignite.internal.tx.impl.IgniteAbstractTransactionImpl.commitAsync(IgniteAbstractTransactionImpl.java:98)
at
app//org.apache.ignite.internal.sql.engine.tx.QueryTransactionWrapperImpl.commitImplicit(QueryTransactionWrapperImpl.java:46)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$closeAsync$3(AsyncSqlCursorImpl.java:132)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.closeAsync(AsyncSqlCursorImpl.java:132)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:101)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.requestNextAsync(AsyncSqlCursorImpl.java:94)
at
app//org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$4(IgniteSqlImpl.java:360)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
app//org.apache.ignite.internal.sql.engine.SqlQueryProcessor$PrefetchCallback.onPrefetchComplete(SqlQueryProcessor.java:1050)
at
app//org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$3(KeyValueModifyPlan.java:141)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
at
app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83){code}
Full log attached.
was:
#currentLease can return null in a case when there is no lease information on
the current node yet, while the lease may already exist on another node. This
can lead to
PrimaryReplicaExpiredException.
Seems that we've already seen such exceptions on TC:
{code:java}
Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
expired, transaction will be rolled back: [groupId = 59_part_11, expected
enlistment consistency token = 112211838526816298, commit timestamp = null,
current primary replica = null]
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
at
app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
at
[jira] [Created] (IGNITE-22033) Replace PlacementDriver#currentLease with #getPrimaryReplica in ReadWriteTxContext#waitReadyToFinish
Denis Chudov created IGNITE-22033:
-
Summary: Replace PlacementDriver#currentLease with
#getPrimaryReplica in ReadWriteTxContext#waitReadyToFinish
Key: IGNITE-22033
URL: https://issues.apache.org/jira/browse/IGNITE-22033
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
#currentLease can return null in a case when there is no lease information on
the current node yet, while the lease may already exist on another node. This
can lead to
PrimaryReplicaExpiredException.
Seems that we've already seen such exceptions on TC:
{code:java}
Caused by: org.apache.ignite.internal.tx.impl.PrimaryReplicaExpiredException:
IGN-TX-13 TraceId:2766fa1f-a00e-4c53-b556-7d06fc116229 Primary replica has
expired, transaction will be rolled back: [groupId = 59_part_11, expected
enlistment consistency token = 112211838526816298, commit timestamp = null,
current primary replica = null] at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.waitReadyToFinish(TransactionInflights.java:271)
at
app//org.apache.ignite.internal.tx.impl.TransactionInflights$ReadWriteTxContext.performFinish(TransactionInflights.java:229)
at
app//org.apache.ignite.internal.tx.impl.TxManagerImpl.finish(TxManagerImpl.java:501)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finishInternal(ReadWriteTransactionImpl.java:161)
at
app//org.apache.ignite.internal.tx.impl.ReadWriteTransactionImpl.finish(ReadWriteTransactionImpl.java:140)
at
app//org.apache.ignite.internal.tx.impl.IgniteAbstractTransactionImpl.commitAsync(IgniteAbstractTransactionImpl.java:98)
at
app//org.apache.ignite.internal.sql.engine.tx.QueryTransactionWrapperImpl.commitImplicit(QueryTransactionWrapperImpl.java:46)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$closeAsync$3(AsyncSqlCursorImpl.java:132)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.closeAsync(AsyncSqlCursorImpl.java:132)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:101)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.requestNextAsync(AsyncSqlCursorImpl.java:94)
at
app//org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$4(IgniteSqlImpl.java:360)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
app//org.apache.ignite.internal.sql.engine.SqlQueryProcessor$PrefetchCallback.onPrefetchComplete(SqlQueryProcessor.java:1050)
at
app//org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$3(KeyValueModifyPlan.java:141)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base@11.0.17/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
app//org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
at
app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21961) Don't remove entries one-by-one for in-memory node on shutdown
[ https://issues.apache.org/jira/browse/IGNITE-21961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21961: Labels: ise (was: ) > Don't remove entries one-by-one for in-memory node on shutdown > -- > > Key: IGNITE-21961 > URL: https://issues.apache.org/jira/browse/IGNITE-21961 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Time Spent: 20m > Remaining Estimate: 0h > > Currently, for in-memory node we remove each entry one-by-one on cluster > deactivation or on node shutdown. If there are a lot of entries in cache it > can take a long time. But it's a redundant action, since all page memory will > be released after deactivation/shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
