[jira] [Updated] (IGNITE-17931) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
[ https://issues.apache.org/jira/browse/IGNITE-17931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17931: Priority: Blocker (was: Major) > Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. > --- > > Key: IGNITE-17931 > URL: https://issues.apache.org/jira/browse/IGNITE-17931 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Blocker > Labels: ignite-3 > > Previously blocking fut.join() contains in SchemaManager#tableSchema after > refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary > to remove blocking approach. > [1] > https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20467) Use replica message instead of directly using raft client when building indexes
[ https://issues.apache.org/jira/browse/IGNITE-20467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20467: - Ignite Flags: (was: Release Notes Required) > Use replica message instead of directly using raft client when building > indexes > --- > > Key: IGNITE-20467 > URL: https://issues.apache.org/jira/browse/IGNITE-20467 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *org.apache.ignite.internal.table.distributed.index.IndexBuilder* uses a raft > client, I think it’s worth changing this to using a replication message to > get rid of the implementation of the replication protocol. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20490) Update the snappy dependency in order to fix CVEs
[
https://issues.apache.org/jira/browse/IGNITE-20490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768882#comment-17768882
]
Ignite TC Bot commented on IGNITE-20490:
{panel:title=Branch: [pull/10957/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10957/head] Base: [master] : New Tests
(7)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7350671]]
* {color:#013220}IgniteCalciteTestSuite:
SqlDiagnosticIntegrationTest.testThreadPoolMetrics - PASSED{color}
{color:#8b}Queries 1{color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=7350716]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BPlusTreeMetricsTest.testDisableStatistics - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BPlusTreeMetricsTest.testDisableMetrics - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BPlusTreeMetricsTest.testValues - PASSED{color}
{color:#8b}Queries 1 (lazy=true){color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=7350717]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
BPlusTreeMetricsTest.testDisableStatistics - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
BPlusTreeMetricsTest.testDisableMetrics - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
BPlusTreeMetricsTest.testValues - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7350747buildTypeId=IgniteTests24Java8_RunAll]
> Update the snappy dependency in order to fix CVEs
> -
>
> Key: IGNITE-20490
> URL: https://issues.apache.org/jira/browse/IGNITE-20490
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The dependency needs to be updated to fix CVE:
> https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20492) NPE in PartitionReplicaListener's primary replica retrieval
Kirill Sizov created IGNITE-20492:
--
Summary: NPE in PartitionReplicaListener's primary replica
retrieval
Key: IGNITE-20492
URL: https://issues.apache.org/jira/browse/IGNITE-20492
Project: Ignite
Issue Type: Bug
Reporter: Kirill Sizov
PartitionReplicaListener.ensureReplicaIsPrimary has the following block of code
{code:java}
if (expectedTerm != null) {
return placementDriver.getPrimaryReplica(replicationGroupId, now)
.thenCompose(primaryReplica -> {
long currentEnlistmentConsistencyToken =
primaryReplica.getStartTime().longValue();
{code}
However, according to the placementDriver's contract, {{getPrimaryReplica}} can
complete with null:
{quote}
Same as awaitPrimaryReplica(ReplicationGroupId, HybridTimestamp) despite the
fact that given method await logic is bounded. It will wait for a primary
replica for a reasonable period of time, and complete a future with null if a
matching lease isn't found. Generally speaking reasonable here means enough for
distribution across cluster nodes.
{quote}
In that case ensureReplicaIsPrimary will crash with NPE:
{noformat}
... 3 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$155(PartitionReplicaListener.java:2397)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) ~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.invokeOnRevisionCallback(WatchProcessor.java:247)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$2(WatchProcessor.java:148)
~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
~[?:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20410) ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication fails with ReplicationTimeoutException
[
https://issues.apache.org/jira/browse/IGNITE-20410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768780#comment-17768780
]
Roman Puchkovskiy commented on IGNITE-20410:
It turns out that the test fails not because the leader gets changed, but
because CheckCatalogVersionOnActionRequest recently broke client leaderId
refresh protocol.
When a leader changes, a RAFT client might still cache the old leaderId. When
it sends an ActionRequest, the server verifies that it's the leader, and if
not, it returns an error with code EPERM and the new leaderId, which the client
saves and retries the request.
The recently added CheckCatalogVersionOnActionRequest makes its catalog version
check before this standard check for leadership, so it never returns the actual
leaderId to the client.
The test mentioned in this issue fails when node1 becomes the partition leader,
so node0's client caches that node1 is the leader. As the leaderId refresh
protocol is broken, node0's client never gets idea that node1 is not the leader
anymore, so attempts to add an ActionRequest fails.
The issue that was originally suspected to be the culprit of the failures still
seems to be possible, but I was not able to reproduce it, so at least it's
extremely rare. I created IGNITE-20489 to address it separately.
> ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication
> fails with ReplicationTimeoutException
> ---
>
> Key: IGNITE-20410
> URL: https://issues.apache.org/jira/browse/IGNITE-20410
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication
> fails with ReplicationTimeoutException because of Metadata unavailability on
> replication node.
> With some extra debug output I got following result:
> {code:java}
> applyUpdateCommand
> applyCmdWithExceptionHandling messageType = 43, groupType = 9
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> ...
> ...
> ...
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> applyCmdWithExceptionHandling RuntimeException
> Replication is timed out [replicaGrpId=1_part_0]
> org.apache.ignite.tx.TransactionException: IGN-REP-3
> TraceId:b5ea497a-7985-414a-8b44-8a880704bf80 Replication is timed out
> [replicaGrpId=1_part_0]
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:378)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:461)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:378)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1630)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:521)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:911)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
> at
>
[jira] [Updated] (IGNITE-20491) .NET: Thin 3.0: Introduce configurable operation timeout
[ https://issues.apache.org/jira/browse/IGNITE-20491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20491: Description: Currently we have `SocketTimeout` which is only used for handshake and heartbeats, which means we use it to check if the server and network are responsive. However, other operations (put, get, compute, etc) can take any amount of time. Investigate if a general operation timeout can be useful. > .NET: Thin 3.0: Introduce configurable operation timeout > > > Key: IGNITE-20491 > URL: https://issues.apache.org/jira/browse/IGNITE-20491 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently we have `SocketTimeout` which is only used for handshake and > heartbeats, which means we use it to check if the server and network are > responsive. > However, other operations (put, get, compute, etc) can take any amount of > time. > Investigate if a general operation timeout can be useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20491) .NET: Thin 3.0: Introduce configurable operation timeout
Pavel Tupitsyn created IGNITE-20491: --- Summary: .NET: Thin 3.0: Introduce configurable operation timeout Key: IGNITE-20491 URL: https://issues.apache.org/jira/browse/IGNITE-20491 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20468) .NET: Thin 3.0: Intermittent timeouts on TC
[ https://issues.apache.org/jira/browse/IGNITE-20468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768765#comment-17768765 ] Pavel Tupitsyn commented on IGNITE-20468: - Hanging tests are caused by IGNITE-17931 (deadlock in *SchemaRegistryImpl.waitLatestSchema* ). However, we should add timeouts and avoid waiting forever on some client operations. > .NET: Thin 3.0: Intermittent timeouts on TC > --- > > Key: IGNITE-20468 > URL: https://issues.apache.org/jira/browse/IGNITE-20468 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Increased number of .NET TC builds fail with timeout errors. Investigate > whether some specific test or behavior is causing this, whether this is a > problem on server side, etc > * > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests?branch=%3Cdefault%3E=builds#all-projects > * `Fail to issue RPC to > org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, > consecutiveErrorTimes=10, error=Status[ETIMEDOUT<1010>: RPC exception:null]` > * `OneTimeSetUp: System.TimeoutException : The operation has timed out.` > ** Which operation? Why is there no stack trace? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20490) Update the snappy dependency in order to fix CVEs
Maxim Muzafarov created IGNITE-20490: Summary: Update the snappy dependency in order to fix CVEs Key: IGNITE-20490 URL: https://issues.apache.org/jira/browse/IGNITE-20490 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.16 The dependency needs to be updated to fix CVE: https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20410) ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication fails with ReplicationTimeoutException
[
https://issues.apache.org/jira/browse/IGNITE-20410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-20410:
--
Assignee: Roman Puchkovskiy
> ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication
> fails with ReplicationTimeoutException
> ---
>
> Key: IGNITE-20410
> URL: https://issues.apache.org/jira/browse/IGNITE-20410
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItSchemaSyncAndReplicationTest#laggingSchemasPreventPartitionDataReplication
> fails with ReplicationTimeoutException because of Metadata unavailability on
> replication node.
> With some extra debug output I got following result:
> {code:java}
> applyUpdateCommand
> applyCmdWithExceptionHandling messageType = 43, groupType = 9
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> ...
> ...
> ...
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> complete resp = ErrorResponseImpl [errorCode=1009, errorMsg=Metadata not yet
> available, group '1_part_0', required level 3; rejecting ActionRequest with
> EBUSY., leaderId=null], err = null
> applyCmdWithExceptionHandling RuntimeException
> Replication is timed out [replicaGrpId=1_part_0]
> org.apache.ignite.tx.TransactionException: IGN-REP-3
> TraceId:b5ea497a-7985-414a-8b44-8a880704bf80 Replication is timed out
> [replicaGrpId=1_part_0]
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:378)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:461)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:378)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1630)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:521)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:911)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:495)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:911)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
> at
> app//org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:97)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841)
> at
> java.base@18.0.2/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
> at
>
[jira] [Created] (IGNITE-20489) Tests that transfer leadership must make sure it doesn't change spontaneously
Roman Puchkovskiy created IGNITE-20489: -- Summary: Tests that transfer leadership must make sure it doesn't change spontaneously Key: IGNITE-20489 URL: https://issues.apache.org/jira/browse/IGNITE-20489 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 At least ItSchemaSyncAndReplicationTest and ItTableRaftSnapshotsTest transfer leadership to chosen nodes in a cluster. If the leadership gets transferred from the node chosen by the test (this might happen due to a GC pause, for example), the test might fail. We could forbid a node to request votes for becoming a leader by blocking RequestVoteRequests either on the network level (substituting the response with a fake response with granted=false) or on the server (by substituting RequestVoteRequestProcessor). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20488) Add metrics for count of page merges/splits in BPlusTree
Aleksey Plekhanov created IGNITE-20488: -- Summary: Add metrics for count of page merges/splits in BPlusTree Key: IGNITE-20488 URL: https://issues.apache.org/jira/browse/IGNITE-20488 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov It will be helpful to have such metrics as count of merges/splits in BPlusTree -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20487) Add system views for IgniteStripedThreadPoolExecutor
Aleksey Plekhanov created IGNITE-20487:
--
Summary: Add system views for IgniteStripedThreadPoolExecutor
Key: IGNITE-20487
URL: https://issues.apache.org/jira/browse/IGNITE-20487
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Currently, we have two views for {{StripedExecutor}}'s ({{stripedExecSvc}},
{{dataStreamerExecSvc}}), but we have another type of striped executor:
{{IgniteStripedThreadPoolExecutor}} ({{rebalanceStripedExecSvc}},
{{callbackExecSvc}}, calcite query task executor), it will be helpful to have
system views for these executors too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20464) Add consistent id to the index validate result.
[ https://issues.apache.org/jira/browse/IGNITE-20464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-20464: - Assignee: Vladimir Steshin > Add consistent id to the index validate result. > --- > > Key: IGNITE-20464 > URL: https://issues.apache.org/jira/browse/IGNITE-20464 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Time Spent: 1h > Remaining Estimate: 0h > > Output of '--cache validate_indexes' command might have node consistent id > like the result of the idle verify. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20486) Protect write intent resolution with busy locks
Kirill Sizov created IGNITE-20486: -- Summary: Protect write intent resolution with busy locks Key: IGNITE-20486 URL: https://issues.apache.org/jira/browse/IGNITE-20486 Project: Ignite Issue Type: Task Reporter: Kirill Sizov *Motivation* We want to make sure that write intent resolution is not performed on a stopping/stopped node. *Definition of Done* Write intent resolution is performed under the busy lock. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20486) Protect write intent resolution with busy locks
[ https://issues.apache.org/jira/browse/IGNITE-20486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-20486: -- Assignee: Kirill Sizov > Protect write intent resolution with busy locks > --- > > Key: IGNITE-20486 > URL: https://issues.apache.org/jira/browse/IGNITE-20486 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > *Motivation* > We want to make sure that write intent resolution is not performed on a > stopping/stopped node. > *Definition of Done* > Write intent resolution is performed under the busy lock. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20482) Simplify write intent resolution in PartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-20482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20482: - Ignite Flags: (was: Docs Required,Release Notes Required) > Simplify write intent resolution in PartitionReplicaListener > > > Key: IGNITE-20482 > URL: https://issues.apache.org/jira/browse/IGNITE-20482 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a refactoring task to make the code related to write intent > resolution more readable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20482) Simplify write intent resolution in PartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-20482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768657#comment-17768657 ] Alexander Lapin commented on IGNITE-20482: -- LGTM, merged. Thank you! > Simplify write intent resolution in PartitionReplicaListener > > > Key: IGNITE-20482 > URL: https://issues.apache.org/jira/browse/IGNITE-20482 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a refactoring task to make the code related to write intent > resolution more readable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer
[ https://issues.apache.org/jira/browse/IGNITE-20474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20474: Epic Link: IGNITE-19479 > .NET: Thin 3.0: Source-generated serializer > --- > > Key: IGNITE-20474 > URL: https://issues.apache.org/jira/browse/IGNITE-20474 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, .NET thin client relies on reflection to emit > serialization/deserialization code. This approach is very flexible and > user-friendly, but does not work with [Native > AOT|https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows], > which is getting increasingly popular. > Provide an additional serialization mechanism based on [Source > Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] > that does not require reflection. > The difficult part is that we don't know the table schema at compile time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768630#comment-17768630 ] Kirill Tkalenko commented on IGNITE-20339: -- Please do not get rid of *IndexEvent* they are needed to build indexes in IGNITE-20330. > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent*, > *org.apache.ignite.internal.table.event.TableEvent* and > *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20485) Allow to configure lease interval
Vladislav Pyatkov created IGNITE-20485:
--
Summary: Allow to configure lease interval
Key: IGNITE-20485
URL: https://issues.apache.org/jira/browse/IGNITE-20485
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
*Motivation*
Currently, the lease interval depends on the lease update frequency and is
calculated like this:
{code:title=LeaseUpdater}
private static final long LEASE_INTERVAL = 10 * UPDATE_LEASE_MS;
{code}
The interval is impossible to configure; that way, it makes the test longer
than it can be with a short lease interval.
*Implementation notes*
Do not forget to check TODOs.
*Definition of done*
Allow to configure lease intervat at least the system properties to use in the
test.
Also, the ability to configure should be available through the Ignite property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20485) Allow to configure lease interval
[
https://issues.apache.org/jira/browse/IGNITE-20485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20485:
---
Description:
*Motivation*
Currently, the lease interval depends on the lease update frequency and is
calculated like this:
{code:title=LeaseUpdater.java}
private static final long LEASE_INTERVAL = 10 * UPDATE_LEASE_MS;
{code}
The interval is impossible to configure; that way, it makes the test longer
than it can be with a short lease interval.
*Implementation notes*
Do not forget to check TODOs.
*Definition of done*
Allow to configure lease intervat at least the system properties to use in the
test.
Also, the ability to configure should be available through the Ignite property.
was:
*Motivation*
Currently, the lease interval depends on the lease update frequency and is
calculated like this:
{code:title=LeaseUpdater}
private static final long LEASE_INTERVAL = 10 * UPDATE_LEASE_MS;
{code}
The interval is impossible to configure; that way, it makes the test longer
than it can be with a short lease interval.
*Implementation notes*
Do not forget to check TODOs.
*Definition of done*
Allow to configure lease intervat at least the system properties to use in the
test.
Also, the ability to configure should be available through the Ignite property.
> Allow to configure lease interval
> -
>
> Key: IGNITE-20485
> URL: https://issues.apache.org/jira/browse/IGNITE-20485
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Currently, the lease interval depends on the lease update frequency and is
> calculated like this:
> {code:title=LeaseUpdater.java}
> private static final long LEASE_INTERVAL = 10 * UPDATE_LEASE_MS;
> {code}
> The interval is impossible to configure; that way, it makes the test longer
> than it can be with a short lease interval.
> *Implementation notes*
> Do not forget to check TODOs.
> *Definition of done*
> Allow to configure lease intervat at least the system properties to use in
> the test.
> Also, the ability to configure should be available through the Ignite
> property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20484) NPE when some operation occurs when the primary replica is changing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20484:
---
Summary: NPE when some operation occurs when the primary replica is
changing (was: NPE when some operation pocessed when the primary replica is
changeing)
> NPE when some operation occurs when the primary replica is changing
> ---
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Implementation notes*
> Do not forget to check all places where the issue is mentioned (espatially in
> TODO section).
> *Difinition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20484) NPE when some operation pocessed when the primary replica is changeing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20484:
---
Description:
*Motivation*
It happens that when the request is created, the primary replica is in this
node, but when the request is executed in the replica, it has already lost its
role.
{noformat}
[2023-09-25T11:03:24,408][WARN
][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
process replica request [request=ReadWriteSingleRowReplicaRequestImpl
[binaryRowMessage=BinaryRowMessageImpl
[binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
timestampLong=24742430588928,
transactionId=018acb5d-4e54-0006--705db0b1]]
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
~[main/:?]
at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) ~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
~[main/:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
... 15 more
{noformat}
*Implementation notes*
Do not forget to check all places where the issue is mentioned (espatially in
TODO section).
*Difinition of done*
In this case, we should throw the correct exception because the request cannot
be handled in this replica anymore, and the matched transaction will be rolled
back.
was:
*Motivation*
It happens that when the request is created, the primary replica is in this
node, but when the request is executed in the replica, it has already lost its
role.
{noformat}
[2023-09-25T11:03:24,408][WARN
][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
process replica request [request=ReadWriteSingleRowReplicaRequestImpl
[binaryRowMessage=BinaryRowMessageImpl
[binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
timestampLong=24742430588928,
transactionId=018acb5d-4e54-0006--705db0b1]]
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
[jira] [Updated] (IGNITE-20484) NPE when some operation pocessed when the primary replica is changeing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20484:
---
Description:
*Motivation*
It happens that when the request is created, the primary replica is in this
node, but when the request is executed in the replica, it has already lost its
role.
{noformat}
[2023-09-25T11:03:24,408][WARN
][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
process replica request [request=ReadWriteSingleRowReplicaRequestImpl
[binaryRowMessage=BinaryRowMessageImpl
[binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
timestampLong=24742430588928,
transactionId=018acb5d-4e54-0006--705db0b1]]
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
~[main/:?]
at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) ~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
~[main/:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
... 15 more
{noformat}
*Difinition of done*
In this case, we should throw the correct exception because the request cannot
be handled in this replica anymore, and the matched transaction will be rolled
back.
was:
It happens that when the request is created, the primary replica is in this
node, but when the request is executed in the replica, it has already lost its
role. In this case, we should throw the correct exception because the request
cannot be handled in this replica anymore, and the matched transaction will be
rolled back.
{noformat}
[2023-09-25T11:03:24,408][WARN
][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
process replica request [request=ReadWriteSingleRowReplicaRequestImpl
[binaryRowMessage=BinaryRowMessageImpl
[binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
timestampLong=24742430588928,
transactionId=018acb5d-4e54-0006--705db0b1]]
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
[jira] [Updated] (IGNITE-20484) NPE when some operation pocessed when the primary replica is changeing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20484:
---
Labels: ignite-3 (was: )
> NPE when some operation pocessed when the primary replica is changeing
> --
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Difinition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20484) NPE when some operation pocessed when the primary replica is changeing
Vladislav Pyatkov created IGNITE-20484:
--
Summary: NPE when some operation pocessed when the primary replica
is changeing
Key: IGNITE-20484
URL: https://issues.apache.org/jira/browse/IGNITE-20484
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
It happens that when the request is created, the primary replica is in this
node, but when the request is executed in the replica, it has already lost its
role. In this case, we should throw the correct exception because the request
cannot be handled in this replica anymore, and the matched transaction will be
rolled back.
{noformat}
[2023-09-25T11:03:24,408][WARN
][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
process replica request [request=ReadWriteSingleRowReplicaRequestImpl
[binaryRowMessage=BinaryRowMessageImpl
[binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
timestampLong=24742430588928,
transactionId=018acb5d-4e54-0006--705db0b1]]
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
~[main/:?]
at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) ~[?:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
~[main/:?]
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
~[main/:?]
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
~[main/:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
... 15 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20426) Sync deprecated methods in the ClientCacheConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-20426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20426:
-
Ignite Flags: Docs Required,Release Notes Required (was: Release Notes
Required)
> Sync deprecated methods in the ClientCacheConfiguration
> ---
>
> Key: IGNITE-20426
> URL: https://issues.apache.org/jira/browse/IGNITE-20426
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Anastasia Iakimova
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following properties are deprecated in {{CacheConfiguration}} but are
> still actual in {{ClientCacheConfiguration}}:
> * getDefaultLockTimeout
> * getRebalanceBatchSize
> * getRebalanceBatchesPrefetchCount
> * getRebalanceDelay
> * getRebalanceThrottle
> * getRebalanceTimeout
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20483) MessagingService error on load
Alexander Belyak created IGNITE-20483:
-
Summary: MessagingService error on load
Key: IGNITE-20483
URL: https://issues.apache.org/jira/browse/IGNITE-20483
Project: Ignite
Issue Type: Bug
Components: networking
Affects Versions: 3.0
Reporter: Alexander Belyak
Basic test like:
{code:java}
ClusterNode target = node0.clusterNodes().stream().filter(node ->
!node.name().equals(firstNodeName)).findAny().orElseThrow();
TestHugeMessage msg = new TestHugeMessage(new byte[100500]);
for (int i = 100_000; i < 100_000_000; i++) {
if (i % 100_000 == 0) {
System.out.println("i=" + i);
}
ms1.send(target, msg);
} {code}
leads to critical error:
{noformat}
[2023-09-25T11:59:57,088][WARN
][imst_cms_0-srv-worker-4][RecoveryServerHandshakeManager] Handshake rejected
by client: imst_cms_0:2dcea174-58b5-4a8d-bf58-acaafdd64365 is stale, server
should be restarted so that clients can connect
[2023-09-25T11:59:57,090][ERROR][imst_cms_0-srv-worker-4][FailureHandler]
Critical failure
org.apache.ignite.lang.IgniteException: Handshake rejected by client:
imst_cms_0:2dcea174-58b5-4a8d-bf58-acaafdd64365 is stale, server should be
restarted so that clients can connect
at
org.apache.ignite.internal.network.recovery.RecoveryServerHandshakeManager.onMessage(RecoveryServerHandshakeManager.java:197)
[ignite-network-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.network.netty.HandshakeHandler.channelRead(HandshakeHandler.java:92)
[ignite-network-3.0.0-SNAPSHOT.jar:?]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
[netty-codec-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
[netty-codec-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
[netty-transport-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[netty-common-4.1.87.Final.jar:4.1.87.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-common-4.1.87.Final.jar:4.1.87.Final]
at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20482) Simplify write intent resolution in PartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-20482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-20482: --- Labels: ignite-3 (was: ) > Simplify write intent resolution in PartitionReplicaListener > > > Key: IGNITE-20482 > URL: https://issues.apache.org/jira/browse/IGNITE-20482 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > This is a refactoring task to make the code related to write intent > resolution more readable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20482) Simplify write intent resolution in PartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-20482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-20482: -- Assignee: Kirill Sizov > Simplify write intent resolution in PartitionReplicaListener > > > Key: IGNITE-20482 > URL: https://issues.apache.org/jira/browse/IGNITE-20482 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > > This is a refactoring task to make the code related to write intent > resolution more readable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20482) Simplify write intent resolution in PartitionReplicaListener
Kirill Sizov created IGNITE-20482: -- Summary: Simplify write intent resolution in PartitionReplicaListener Key: IGNITE-20482 URL: https://issues.apache.org/jira/browse/IGNITE-20482 Project: Ignite Issue Type: Task Reporter: Kirill Sizov This is a refactoring task to make the code related to write intent resolution more readable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20442) Sql. Extend grammar with transaction related statements.
[
https://issues.apache.org/jira/browse/IGNITE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20442:
---
Description:
In order to process multistatement queries we need to support the following sql
grammar to start/finish transactions.
{code}
::=
START TRANSACTION []
::= READ ONLY | READ WRITE
{code}
{code}
::=
COMMIT
{code}
was:
In order to process multistatement queries we need to support the following sql
grammar to start/finish transactions.
{code}
::=
START TRANSACTION []
::= READ ONLY | READ WRITE
{code}
{code}
::=
COMMIT
{code}
> Sql. Extend grammar with transaction related statements.
>
>
> Key: IGNITE-20442
> URL: https://issues.apache.org/jira/browse/IGNITE-20442
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> In order to process multistatement queries we need to support the following
> sql grammar to start/finish transactions.
> {code}
> ::=
> START TRANSACTION []
> ::= READ ONLY | READ WRITE
> {code}
> {code}
> ::=
> COMMIT
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (IGNITE-20460) Too many files with unapproved license
[
https://issues.apache.org/jira/browse/IGNITE-20460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Egorov closed IGNITE-20460.
-
> Too many files with unapproved license
> --
>
> Key: IGNITE-20460
> URL: https://issues.apache.org/jira/browse/IGNITE-20460
> Project: Ignite
> Issue Type: Bug
> Components: build, documentation
>Reporter: Artem Egorov
>Assignee: Igor Gusev
>Priority: Critical
>
> After merging IGNITE-20431, the project build began to fail with an "Too many
> files with unapproved license" error:
> {quote}1 Unknown Licenses
> * Files with unapproved
> licenses: docs/_docs/installation/upgrades.adoc
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20426) Sync deprecated methods in the ClientCacheConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-20426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768586#comment-17768586
]
Ignite TC Bot commented on IGNITE-20426:
{panel:title=Branch: [pull/10948/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10948/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7346594buildTypeId=IgniteTests24Java8_RunAll]
> Sync deprecated methods in the ClientCacheConfiguration
> ---
>
> Key: IGNITE-20426
> URL: https://issues.apache.org/jira/browse/IGNITE-20426
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Anastasia Iakimova
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following properties are deprecated in {{CacheConfiguration}} but are
> still actual in {{ClientCacheConfiguration}}:
> * getDefaultLockTimeout
> * getRebalanceBatchSize
> * getRebalanceBatchesPrefetchCount
> * getRebalanceDelay
> * getRebalanceThrottle
> * getRebalanceTimeout
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20426) Sync deprecated methods in the ClientCacheConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-20426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20426:
-
Fix Version/s: 2.16
> Sync deprecated methods in the ClientCacheConfiguration
> ---
>
> Key: IGNITE-20426
> URL: https://issues.apache.org/jira/browse/IGNITE-20426
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Anastasia Iakimova
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following properties are deprecated in {{CacheConfiguration}} but are
> still actual in {{ClientCacheConfiguration}}:
> * getDefaultLockTimeout
> * getRebalanceBatchSize
> * getRebalanceBatchesPrefetchCount
> * getRebalanceDelay
> * getRebalanceThrottle
> * getRebalanceTimeout
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20434) Provide jdbc port in NodeState REST API
[ https://issues.apache.org/jira/browse/IGNITE-20434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768566#comment-17768566 ] Dmitry Baranov edited comment on IGNITE-20434 at 9/25/23 7:47 AM: -- github PR link [https://github.com/apache/ignite-3/pull/2607] was (Author: JIRAUSER299704): github https://github.com/apache/ignite-3/pull/2607 > Provide jdbc port in NodeState REST API > --- > > Key: IGNITE-20434 > URL: https://issues.apache.org/jira/browse/IGNITE-20434 > Project: Ignite > Issue Type: Task > Components: cli, rest >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > To avoid extra rest call on cli connect command it is better to provide jdbc > port in node state rest call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20434) Provide jdbc port in NodeState REST API
[ https://issues.apache.org/jira/browse/IGNITE-20434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Baranov updated IGNITE-20434: github https://github.com/apache/ignite-3/pull/2607 > Provide jdbc port in NodeState REST API > --- > > Key: IGNITE-20434 > URL: https://issues.apache.org/jira/browse/IGNITE-20434 > Project: Ignite > Issue Type: Task > Components: cli, rest >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > To avoid extra rest call on cli connect command it is better to provide jdbc > port in node state rest call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20434) Provide jdbc port in NodeState REST API
[ https://issues.apache.org/jira/browse/IGNITE-20434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Baranov updated IGNITE-20434: Labels: ignite-3 ignite-3-cli-tool (was: ) > Provide jdbc port in NodeState REST API > --- > > Key: IGNITE-20434 > URL: https://issues.apache.org/jira/browse/IGNITE-20434 > Project: Ignite > Issue Type: Task > Components: cli, rest >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > To avoid extra rest call on cli connect command it is better to provide jdbc > port in node state rest call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20339: -- Labels: ignite-3 tech-debt (was: ignite-3) > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent*, > *org.apache.ignite.internal.table.event.TableEvent* and > *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20397) java.lang.AssertionError: Group of the event is unsupported
[
https://issues.apache.org/jira/browse/IGNITE-20397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-20397:
---
Description:
{code:java}
java.lang.AssertionError: Group of the event is unsupported
[nodeId=<11_part_18/isaat_n_2>,
event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
~[disruptor-3.3.7.jar:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]
The root cause:
# StripedDisruptor.StripeEntryHandler#onEvent method gets handler from
StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
# In some cases the `subscribers` map is cleared by invocation of
StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler
receives event with SafeTimeSyncCommandImpl.
# It produces an assertion error: `assert handler != null`
The issue is not caused by the catalog feature changes.
It possible to reproduced it if add Thread.sleep in StripeEntryHandler#onEvent.
UPD:
The issue is reproduced when I run the ItSqlAsynchronousApiTest#batchIncomplete
with RepeatedTest annotation. In this case the cluster is not restarted after
each tests.
When I change test class to "start cluster, create table, drop table, stop
cluster" then the issue is not reproduced.
We decided that we can use LOG.warn() instead of an assert:
* If handler == null then print assert
* else do handler.onEvent
was:
{code:java}
java.lang.AssertionError: Group of the event is unsupported
[nodeId=<11_part_18/isaat_n_2>,
event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
~[disruptor-3.3.7.jar:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]
The root cause:
# StripedDisruptor.StripeEntryHandler#onEvent method gets handler from
StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
# In some cases the `subscribers` map is cleared by invocation of
StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler
receives event with SafeTimeSyncCommandImpl.
# It produces an assertion error: `assert handler != null`
The issue is not caused by the catalog feature changes.
It possible to reproduced it if add Thread.sleep in StripeEntryHandler#onEvent.
Originally it was reproduced on a table dropping. But it possible to reproduce
it on a table creation if set "IDLE_SAFE_TIME_PROPAGATION_PERIOD_MILLISECONDS =
500;".
> java.lang.AssertionError: Group of the event is unsupported
> ---
>
> Key: IGNITE-20397
> URL: https://issues.apache.org/jira/browse/IGNITE-20397
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> java.lang.AssertionError: Group of the event is unsupported
> [nodeId=<11_part_18/isaat_n_2>,
> event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
> ~[disruptor-3.3.7.jar:?]
> at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]
> The root cause:
> # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from
> StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
> # In some cases the `subscribers` map is cleared by
[jira] [Updated] (IGNITE-19894) Sql. Correct processing for case sensitivity column names
[
https://issues.apache.org/jira/browse/IGNITE-19894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19894:
Summary: Sql. Correct processing for case sensitivity column names (was:
Sql. Can`t access column created in lower registry through Tuple api)
> Sql. Correct processing for case sensitivity column names
> -
>
> Key: IGNITE-19894
> URL: https://issues.apache.org/jira/browse/IGNITE-19894
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Starting point for example [1]
> {code:java}
> checkDdl(true, ses, "CREATE TABLE my (c1 INT PRIMARY KEY, c2 INT, c3
> VARCHAR)");
> Session ses = sql.createSession();
> result.intValue("C2"); <--- Ok
> result.intValue("c2"); <--- throws Column doesn't exist [name=c2]
> {code}
> [1] InternalSchemaTest#testDropAndAddColumns
> Seems quotations at all not supported by now,
> DdlSqlToCommandConverter#convertCreateTable
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19223) Implement accumulation of schema updates in CatalogService
[ https://issues.apache.org/jira/browse/IGNITE-19223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-19223. Fix Version/s: 3.0.0-beta2 Resolution: Fixed This was fixed when implementing IGNITE-19502 > Implement accumulation of schema updates in CatalogService > -- > > Key: IGNITE-19223 > URL: https://issues.apache.org/jira/browse/IGNITE-19223 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > CatalogService implementation should hold the historical information about > schema updates. This means that: > # It needs to load the known history of schema updates on node start > # It should subsribe to new schema updates -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest# testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
[
https://issues.apache.org/jira/browse/IGNITE-20412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-20412:
---
Summary: Fix ItIgniteDistributionZoneManagerNodeRestartTest#
testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart (was:
Fix
ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart)
> Fix ItIgniteDistributionZoneManagerNodeRestartTest#
> testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
> -
>
> Key: IGNITE-20412
> URL: https://issues.apache.org/jira/browse/IGNITE-20412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> h3. Motivation
> org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
> started to fall in the catalog-feature branch and fails in the main branch
> after catalog-feature is merged
> [https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
> {code:java}
> java.lang.AssertionError:
> Expected: is <[]>
> but: was <[A]>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
> at
> org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
> {code}
> h3. Implementation notes
> The root cause:
> # This test changes metaStorageManager behavior and it throws expected
> exception on ms.invoke.
> # The test alters zone with new filter.
> # DistributionZoneManager#onUpdateFilter return a future from
> saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
> # The future is completed exceptionally and
> WatchProcessor#notificationFuture will be completed exceptionally.
> # Next updates will not be handled properly because notificationFuture is
> completed exceptionally.
> We have already created tickets obout exception handling:
> * https://issues.apache.org/jira/browse/IGNITE-14693
> * https://issues.apache.org/jira/browse/IGNITE-14611
>
> The test scenario is incorrect because the node should be stopped (by failure
> handler) if the ms.invoke failed. We need to rewrite it when the DZM restart
> will be updated.
> UPD1:
> I've tried to rewrite test, so we could not throw exception in metastorage
> handler, but just force thread to wait in this invoke, but this lead the to
> the problem that because we use spy on Standalone Metastorage, and mockito
> use synchronised block when we call ms.invoke, so that leads to the problem
> that blocking of one invoke leads to blocking all other communication with ms.
> Need further investigation how to rewrite this test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
