[jira] [Commented] (IGNITE-19124) Update the current year in website
[ https://issues.apache.org/jira/browse/IGNITE-19124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707360#comment-17707360 ] Aleksandr Nikolaev commented on IGNITE-19124: - [~Daikon] Thanks for review. > Update the current year in website > -- > > Key: IGNITE-19124 > URL: https://issues.apache.org/jira/browse/IGNITE-19124 > Project: Ignite > Issue Type: Improvement > Components: website >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Attachments: Снимок экрана 2023-03-27 в 12.08.38.png, Снимок экрана > 2023-03-27 в 12.25.44.png > > > The site [https://ignite.apache.org/] indicates the date of 2022, it is > necessary to update to the current -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18822) ItIgniteInMemoryNodeRestartTest#inMemoryNodeFullPartitionRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin resolved IGNITE-18822.
--
Assignee: Alexander Lapin
Resolution: Duplicate
> ItIgniteInMemoryNodeRestartTest#inMemoryNodeFullPartitionRestart is flaky
> -
>
> Key: IGNITE-18822
> URL: https://issues.apache.org/jira/browse/IGNITE-18822
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> May be the reason is https://issues.apache.org/jira/browse/IGNITE-18088
> TC build [https://ci.ignite.apache.org/viewLog.html?buildId=7075285]
> {noformat}
> Caused by: org.apache.ignite.tx.TransactionException: IGN-REP-3
> TraceId:30ca0d21-b53a-4282-b8f5-2eee19fb6958 Replication is timed out
> [replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:346)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:429)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:346)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1479)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:471)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:450)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> app//org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$4(ReplicaService.java:98)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base@11.0.16.1/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
> at
> java.base@11.0.16.1/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base@11.0.16.1/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at
> java.base@11.0.16.1/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at
> java.base@11.0.16.1/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.base@11.0.16.1/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Suppressed: java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
> IGN-REP-3 TraceId:37925cca-df1e-4eb2-b533-f7a410fb841e Replication is timed
> out [replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
> 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$UniRun.tryFire(CompletableFuture.java:777)
> ... 11 more
> Caused by:
> org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
> IGN-REP-3 TraceId:37925cca-df1e-4eb2-b533-f7a410fb841e Replication is timed
> out [replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
> ... 9 more
> Caused by:
> org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
> IGN-REP-3 TraceId:30ca0d21-b53a-4282-b8f5-2eee19fb6958 Replication is timed
> out [replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
> ... 9 more{noformat}
> h3. Implementation Notes
> "Replication is timed out" issue was probably fixed wihtin
> https://issues.apache.org/jira/browse/IGNITE-19059 and
> https://issues.apache.org/jira/browse/IGNITE-19022
>
[jira] [Commented] (IGNITE-18948) .NET: Thin 3.0: Add README for NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707292#comment-17707292 ] Igor Sapego commented on IGNITE-18948: -- Looks good to me. > .NET: Thin 3.0: Add README for NuGet package > > > Key: IGNITE-18948 > URL: https://issues.apache.org/jira/browse/IGNITE-18948 > 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 > > > Add a README to the NuGet package with a description and a short getting > started guide with some examples. > This README will be displayed on NuGet.org. > See > https://devblogs.microsoft.com/nuget/write-a-high-quality-readme-for-nuget-packages/ > Topics to cover: > * Getting started > * Major features > ** Record API > ** KV API > ** SQL API > ** Transactions > ** SQL > ** LINQ > ** Logging > ** Metrics > ** Retry, Failover? > ** ??? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19128) Sql. Custom data types. IgniteIndexScan has incorrect types in searchBounds.
[
https://issues.apache.org/jira/browse/IGNITE-19128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19128:
--
Description:
IgniteIndexScanNode has incorrect types in its search bounds although the
filter has correct types in it condition.
Example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE tx (id INTEGER PRIMARY KEY, test_key UUID)");
sql("INSERT INTO tx VALUES(1, ?)", new UUID(2, 0));
sql("CREATE INDEX tx_test_key_idx ON tx (test_key)");
String query = format(
"SELECT * FROM tx WHERE test_key > '{}'::UUID AND test_key <
'{}'::UUID ORDER BY id",
new UUID(1, 0), new UUID(3, 0)
);
sql(query);
}
{code}
Error:
{code:java}
Caused by: java.lang.AssertionError: storageType is class java.util.UUID value
must also be class java.util.UUID but it was:
--0001--0001
at
org.apache.ignite.internal.sql.engine.util.SafeCustomTypeInternalConversion.tryConvertFromInternal(SafeCustomTypeInternalConversion.java:72)
at
org.apache.ignite.internal.sql.engine.util.TypeUtils.fromInternal(TypeUtils.java:330)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toByteBuffer(RowConverter.java:141)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toBinaryTuplePrefix(RowConverter.java:85)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.toBinaryTuplePrefix(IndexScanNode.java:208)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.partitionPublisher(IndexScanNode.java:146)
{code}
Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 291
IgniteSort(sort0=[$0], dir0=[ASC]), id = 290
IgniteIndexScan(table=[[PUBLIC, T]], index=[T_TEST_KEY_IDX], type=[SORTED],
searchBounds=[[RangeBounds
[lowerBound=_UTF-8'--0001--0001',
upperBound=_UTF-8'--0003--0001', lowerInclude=false,
upperInclude=false]]], filters=[AND(>($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), <($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}], collation=[[1]]), id = 273
{code}
But the following works:
{code:java}
@Test
public void test2() {
sql("CREATE TABLE tx (id INTEGER PRIMARY KEY, test_key UUID)");
sql("INSERT INTO tx VALUES(1, ?)", new UUID(2, 0));
sql("CREATE INDEX tx_test_key_idx ON tx (test_key)");
sql("SELECT * FROM tx WHERE test_key > ? AND test_key < ? ORDER BY id",
new UUID(1, 0), new UUID(3, 0));
}
{code}
Working Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 291
IgniteSort(sort0=[$0], dir0=[ASC]), id = 290
IgniteIndexScan(table=[[PUBLIC, TX]], index=[TX_TEST_KEY_IDX],
type=[SORTED], searchBounds=[[RangeBounds [lowerBound=?0, upperBound=?1,
lowerInclude=false, upperInclude=false]]], filters=[AND(>($t1, ?0), <($t1,
?1))], requiredColumns=[{0, 1}], collation=[[1]]), id = 273
{code}
was:
IgniteIndexScanNode has incorrect types in its search bounds although the
filter has correct types in it condition.
Example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE t (id INTEGER PRIMARY KEY, test_key UUID)");
sql("CREATE INDEX t_test_key_idx ON t (test_key)");
sql("SELECT * FROM t WHERE test_key >
'--0001--0001'::UUID AND test_key <
'--0001--0003'::UUID ORDER BY id");
}
{code}
Error:
{code:java}
Caused by: java.lang.AssertionError: storageType is class java.util.UUID value
must also be class java.util.UUID but it was:
--0001--0001
at
org.apache.ignite.internal.sql.engine.util.SafeCustomTypeInternalConversion.tryConvertFromInternal(SafeCustomTypeInternalConversion.java:72)
at
org.apache.ignite.internal.sql.engine.util.TypeUtils.fromInternal(TypeUtils.java:330)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toByteBuffer(RowConverter.java:141)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toBinaryTuplePrefix(RowConverter.java:85)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.toBinaryTuplePrefix(IndexScanNode.java:208)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.partitionPublisher(IndexScanNode.java:146)
{code}
Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 291
IgniteSort(sort0=[$0], dir0=[ASC]), id = 290
IgniteIndexScan(table=[[PUBLIC, T]], index=[T_TEST_KEY_IDX], type=[SORTED],
searchBounds=[[RangeBounds
[lowerBound=_UTF-8'--0001--0001',
upperBound=_UTF-8'--0003--0001', lowerInclude=false,
upperInclude=false]]], filters=[AND(>($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), <($t1,
[jira] [Updated] (IGNITE-19128) Sql. Custom data types. IgniteIndexScan has incorrect types in searchBounds.
[
https://issues.apache.org/jira/browse/IGNITE-19128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19128:
--
Description:
IgniteIndexScanNode has incorrect types in its search bounds although the
filter has correct types in it condition.
Example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE tx (id INTEGER PRIMARY KEY, test_key UUID)");
sql("INSERT INTO tx VALUES(1, ?)", new UUID(2, 0));
sql("CREATE INDEX tx_test_key_idx ON tx (test_key)");
String query = format(
"SELECT * FROM tx WHERE test_key > '{}'::UUID AND test_key <
'{}'::UUID ORDER BY id",
new UUID(1, 0), new UUID(3, 0)
);
sql(query);
}
{code}
Error:
{code:java}
Caused by: java.lang.AssertionError: storageType is class java.util.UUID value
must also be class java.util.UUID but it was:
--0001--0001
at
org.apache.ignite.internal.sql.engine.util.SafeCustomTypeInternalConversion.tryConvertFromInternal(SafeCustomTypeInternalConversion.java:72)
at
org.apache.ignite.internal.sql.engine.util.TypeUtils.fromInternal(TypeUtils.java:330)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toByteBuffer(RowConverter.java:141)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toBinaryTuplePrefix(RowConverter.java:85)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.toBinaryTuplePrefix(IndexScanNode.java:208)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.partitionPublisher(IndexScanNode.java:146)
{code}
Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 344
IgniteSort(sort0=[$0], dir0=[ASC]), id = 343
IgniteIndexScan(table=[[PUBLIC, TX]], index=[TX_TEST_KEY_IDX],
type=[SORTED], searchBounds=[[RangeBounds
[lowerBound=_UTF-8'--0001--',
upperBound=_UTF-8'--0003--', lowerInclude=false,
upperInclude=false]]], filters=[AND(>($t1,
CAST(_UTF-8'--0001--'):UUID NOT NULL), <($t1,
CAST(_UTF-8'--0003--'):UUID NOT NULL))],
requiredColumns=[{0, 1}], collation=[[1]]), id = 326
{code}
But the following works:
{code:java}
@Test
public void test2() {
sql("CREATE TABLE tx (id INTEGER PRIMARY KEY, test_key UUID)");
sql("INSERT INTO tx VALUES(1, ?)", new UUID(2, 0));
sql("CREATE INDEX tx_test_key_idx ON tx (test_key)");
sql("SELECT * FROM tx WHERE test_key > ? AND test_key < ? ORDER BY id",
new UUID(1, 0), new UUID(3, 0));
}
{code}
Working Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 291
IgniteSort(sort0=[$0], dir0=[ASC]), id = 290
IgniteIndexScan(table=[[PUBLIC, TX]], index=[TX_TEST_KEY_IDX],
type=[SORTED], searchBounds=[[RangeBounds [lowerBound=?0, upperBound=?1,
lowerInclude=false, upperInclude=false]]], filters=[AND(>($t1, ?0), <($t1,
?1))], requiredColumns=[{0, 1}], collation=[[1]]), id = 273
{code}
was:
IgniteIndexScanNode has incorrect types in its search bounds although the
filter has correct types in it condition.
Example:
{code:java}
@Test
public void test() {
sql("CREATE TABLE tx (id INTEGER PRIMARY KEY, test_key UUID)");
sql("INSERT INTO tx VALUES(1, ?)", new UUID(2, 0));
sql("CREATE INDEX tx_test_key_idx ON tx (test_key)");
String query = format(
"SELECT * FROM tx WHERE test_key > '{}'::UUID AND test_key <
'{}'::UUID ORDER BY id",
new UUID(1, 0), new UUID(3, 0)
);
sql(query);
}
{code}
Error:
{code:java}
Caused by: java.lang.AssertionError: storageType is class java.util.UUID value
must also be class java.util.UUID but it was:
--0001--0001
at
org.apache.ignite.internal.sql.engine.util.SafeCustomTypeInternalConversion.tryConvertFromInternal(SafeCustomTypeInternalConversion.java:72)
at
org.apache.ignite.internal.sql.engine.util.TypeUtils.fromInternal(TypeUtils.java:330)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toByteBuffer(RowConverter.java:141)
at
org.apache.ignite.internal.sql.engine.exec.RowConverter.toBinaryTuplePrefix(RowConverter.java:85)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.toBinaryTuplePrefix(IndexScanNode.java:208)
at
org.apache.ignite.internal.sql.engine.exec.rel.IndexScanNode.partitionPublisher(IndexScanNode.java:146)
{code}
Plan:
{code:java}
IgniteExchange(distribution=[single]), id = 291
IgniteSort(sort0=[$0], dir0=[ASC]), id = 290
IgniteIndexScan(table=[[PUBLIC, T]], index=[T_TEST_KEY_IDX], type=[SORTED],
searchBounds=[[RangeBounds
[lowerBound=_UTF-8'--0001--0001',
upperBound=_UTF-8'--0003--0001', lowerInclude=false,
upperInclude=false]]], filters=[AND(>($t1,
[jira] [Updated] (IGNITE-19178) Add Sonar to Ignite project to analyze master and release branches
[ https://issues.apache.org/jira/browse/IGNITE-19178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-19178: - Ignite Flags: (was: Docs Required,Release Notes Required) > Add Sonar to Ignite project to analyze master and release branches > -- > > Key: IGNITE-19178 > URL: https://issues.apache.org/jira/browse/IGNITE-19178 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.16 > > > Sonar is a code quality and security tool that is free to open-source > projects and recommended by the INFRA team the link for documentation: > https://cwiki.apache.org/confluence/display/INFRA/SonarCloud+for+ASF+projects > Despite in commonly used by many of the ASF projects, it can have the > following benefits for us: > - visualise simple problems for newcomers to work on; > - see the trends in the source code; > - add an extra layer of static code analysis; > The INFRA ticket: > https://issues.apache.org/jira/browse/INFRA-24415 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19136) Handling timeout on waiting for replica readiness
[
https://issues.apache.org/jira/browse/IGNITE-19136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-19136:
-
Description:
*Motivation*
There are several reasons by the replica can respond _ReplicaNotReadyException_
(storage recovery has not completed yet, indexes have not created). In this
case, required sending AwaitReplicaRequest and don't try requesting any more
until AwaitReplicaResponse doesn't be received.
But the reason is not obvious when we receive a timeout on waiting for the
replica readiness. The result is an exception, which is easy to confuse with
that we don't try handling _ReplicaNotReadyException_:
{noformat}
Replica is not ready
[replicationGroupId=474283c9-a39e-431a-895f-751003052d7a_part_10,
nodeName=irott_n_1]
at
app//org.apache.ignite.internal.replicator.ReplicaManager.sendReplicaUnavailableErrorResponse(ReplicaManager.java:385)
at
app//org.apache.ignite.internal.replicator.ReplicaManager.onReplicaMessageReceived(ReplicaManager.java:167)
at
app//org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:358)
at
app//org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$3(DefaultMessagingService.java:314)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
{noformat}
*Definition of Done*
A message that describes the situation where we cannot wait for replica for
timeout.
{noformat}
Could not wait for the replica become ready for the timeout
[replicationGroupId=474283c9-a39e-431a-895f-751003052d7a_part_10,
nodeName=irott_n_1, timeout=3000]
{noformat}
was:
*Motivation*
There are several reasons by the replica can respond _ReplicaNotReadyException_
(storage recovery has not completed yet, indexes have not created). In this
case, required sending AwaitReplicaRequest and don't try requesting any more
until AwaitReplicaResponse doesn't be received.
But the reason is not obvious when we receive a timeout on waiting for the
replica readiness. The result is an exception, which is easy to confuse with
that we don't try handling _ReplicaNotReadyException_:
{noformat}
Replica is not ready
[replicationGroupId=474283c9-a39e-431a-895f-751003052d7a_part_10,
nodeName=irott_n_1]
at
app//org.apache.ignite.internal.replicator.ReplicaManager.sendReplicaUnavailableErrorResponse(ReplicaManager.java:385)
at
app//org.apache.ignite.internal.replicator.ReplicaManager.onReplicaMessageReceived(ReplicaManager.java:167)
at
app//org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:358)
at
app//org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$3(DefaultMessagingService.java:314)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
{noformat}
*Definition of Done*
A massage that describe the situation where we cannot wait of replica for
timeout.
{noformat}
Could not wait of the replica become ready for the timeout
[replicationGroupId=474283c9-a39e-431a-895f-751003052d7a_part_10,
nodeName=irott_n_1, timeout=3000]
{noformat}
> Handling timeout on waiting for replica readiness
> -
>
> Key: IGNITE-19136
> URL: https://issues.apache.org/jira/browse/IGNITE-19136
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There are several reasons by the replica can respond
> _ReplicaNotReadyException_ (storage recovery has not completed yet, indexes
> have not created). In this case, required sending AwaitReplicaRequest and
> don't try requesting any more until AwaitReplicaResponse doesn't be received.
> But the reason is not obvious when we receive a timeout on waiting for the
> replica readiness. The result is an exception, which is easy to confuse with
> that we don't try handling _ReplicaNotReadyException_:
> {noformat}
> Replica is not ready
> [replicationGroupId=474283c9-a39e-431a-895f-751003052d7a_part_10,
> nodeName=irott_n_1]
> at
> app//org.apache.ignite.internal.replicator.ReplicaManager.sendReplicaUnavailableErrorResponse(ReplicaManager.java:385)
> at
> app//org.apache.ignite.internal.replicator.ReplicaManager.onReplicaMessageReceived(ReplicaManager.java:167)
> at
> app//org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:358)
> at
>
[jira] [Updated] (IGNITE-19120) Raft client should get leader metadata along while getting leader itself
[ https://issues.apache.org/jira/browse/IGNITE-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-19120: -- Description: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change. Necessary metadata is last log index and last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last log index received with leader metadata to make sure that its local storage is up-to-date. Applied index can be not reliable as leader may be being recovered and applied index maybe in progress of catch-up with log index, but it might be useful to know applied index on leaseholder candidate to justify time of waiting for actual storage state. *Definition of done* readIndex call is removed from Replica#waitForActualState. was: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. *Definition of done* readIndex call is removed from Replica#waitForActualState. RaftGroupServiceImpl#refreshAndGetLeaderWithTerm also gets leader metadata along with leader. LeaderWithTerm class is enriched with metadata and (possibly) renamed. > Raft client should get leader metadata along while getting leader itself > > > Key: IGNITE-19120 > URL: https://issues.apache.org/jira/browse/IGNITE-19120 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > This ticket is about TopologyAwareRaftGroupService which can subscribe on > leader change. Necessary metadata is last log index and last applied index in > leader's storage. > This will allow to remove readIndex requests on acceptance of a lease on > leaseholder candidate. As we know that no write commands in replication group > can happen in absence of leaseholder, this means that leaseholder should just > catch up leader's last log index received with leader metadata to make sure > that its local storage is up-to-date. Applied index can be not reliable as > leader may be being recovered and applied index maybe in progress of catch-up > with log index, but it might be useful to know applied index on leaseholder > candidate to justify time of waiting for actual storage state. > *Definition of done* > readIndex call is removed from Replica#waitForActualState. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18822) ItIgniteInMemoryNodeRestartTest#inMemoryNodeFullPartitionRestart is flaky
[
https://issues.apache.org/jira/browse/IGNITE-18822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18822:
-
Description:
May be the reason is https://issues.apache.org/jira/browse/IGNITE-18088
TC build [https://ci.ignite.apache.org/viewLog.html?buildId=7075285]
{noformat}
Caused by: org.apache.ignite.tx.TransactionException: IGN-REP-3
TraceId:30ca0d21-b53a-4282-b8f5-2eee19fb6958 Replication is timed out
[replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
at
app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:346)
at
app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:429)
at
app//org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:346)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.wrapReplicationException(InternalTableImpl.java:1479)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$postEnlist$9(InternalTableImpl.java:471)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlistWithRetry$5(InternalTableImpl.java:450)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
app//org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$4(ReplicaService.java:98)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base@11.0.16.1/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base@11.0.16.1/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base@11.0.16.1/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base@11.0.16.1/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base@11.0.16.1/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base@11.0.16.1/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Suppressed: java.util.concurrent.CompletionException:
org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
IGN-REP-3 TraceId:37925cca-df1e-4eb2-b533-f7a410fb841e Replication is timed out
[replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
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$UniRun.tryFire(CompletableFuture.java:777)
... 11 more
Caused by:
org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
IGN-REP-3 TraceId:37925cca-df1e-4eb2-b533-f7a410fb841e Replication is timed out
[replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
... 9 more
Caused by:
org.apache.ignite.internal.replicator.exception.ReplicationTimeoutException:
IGN-REP-3 TraceId:30ca0d21-b53a-4282-b8f5-2eee19fb6958 Replication is timed out
[replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
... 9 more{noformat}
h3. Implementation Notes
"Replication is timed out" issue was probably fixed wihtin
https://issues.apache.org/jira/browse/IGNITE-19059 and
https://issues.apache.org/jira/browse/IGNITE-19022
I've enabled corresponding test in
https://issues.apache.org/jira/browse/IGNITE-19044
was:
May be the reason is https://issues.apache.org/jira/browse/IGNITE-18088
TC build [https://ci.ignite.apache.org/viewLog.html?buildId=7075285]
{noformat}
Caused by: org.apache.ignite.tx.TransactionException: IGN-REP-3
TraceId:30ca0d21-b53a-4282-b8f5-2eee19fb6958 Replication is timed out
[replicaGrpId=e0f3e99a-6166-4dca-bb1a-bd80450c113c_part_0]
at
app//org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:346)
at
app//org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:429)
at
[jira] [Commented] (IGNITE-19124) Update the current year in website
[ https://issues.apache.org/jira/browse/IGNITE-19124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707267#comment-17707267 ] Alexey Alexandrov commented on IGNITE-19124: [~aonikolaev] merged, you can change issue status to resolved. > Update the current year in website > -- > > Key: IGNITE-19124 > URL: https://issues.apache.org/jira/browse/IGNITE-19124 > Project: Ignite > Issue Type: Improvement > Components: website >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Attachments: Снимок экрана 2023-03-27 в 12.08.38.png, Снимок экрана > 2023-03-27 в 12.25.44.png > > > The site [https://ignite.apache.org/] indicates the date of 2022, it is > necessary to update to the current -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19044) ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader fails
[
https://issues.apache.org/jira/browse/IGNITE-19044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-19044:
Assignee: Alexander Lapin
> ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader fails
> --
>
> Key: IGNITE-19044
> URL: https://issues.apache.org/jira/browse/IGNITE-19044
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
> app//org.apache.ignite.internal.runner.app.ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(ItIgniteInMemoryNodeRestartTest.java:224)
> {code}
> h3. Implementation Notes
> * ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader was fixed
> within https://issues.apache.org/jira/browse/IGNITE-19043
> * And I've also enabled inMemoryNodeFullPartitionRestart(that was disabled
> with https://issues.apache.org/jira/browse/IGNITE-18822) because the problem
> was probably fixed within https://issues.apache.org/jira/browse/IGNITE-19059
> and https://issues.apache.org/jira/browse/IGNITE-19022
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19179) ItClusterManagerTest#testNodeRestart start to fail after LogicalNode introducing
Mirza Aliev created IGNITE-19179: Summary: ItClusterManagerTest#testNodeRestart start to fail after LogicalNode introducing Key: IGNITE-19179 URL: https://issues.apache.org/jira/browse/IGNITE-19179 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19044) ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader fails
[
https://issues.apache.org/jira/browse/IGNITE-19044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19044:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.runner.app.ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(ItIgniteInMemoryNodeRestartTest.java:224)
{code}
h3. Implementation Notes
* ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader was fixed
within https://issues.apache.org/jira/browse/IGNITE-19043
* And I've also enabled inMemoryNodeFullPartitionRestart(that was disabled
with https://issues.apache.org/jira/browse/IGNITE-18822) because the problem
was probably fixed within https://issues.apache.org/jira/browse/IGNITE-19059
and https://issues.apache.org/jira/browse/IGNITE-19022
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
app//org.apache.ignite.internal.runner.app.ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(ItIgniteInMemoryNodeRestartTest.java:224)
{code}
> ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader fails
> --
>
> Key: IGNITE-19044
> URL: https://issues.apache.org/jira/browse/IGNITE-19044
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180) at
> app//org.apache.ignite.internal.runner.app.ItIgniteInMemoryNodeRestartTest.inMemoryNodeRestartNotLeader(ItIgniteInMemoryNodeRestartTest.java:224)
> {code}
> h3. Implementation Notes
> * ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader was fixed
> within https://issues.apache.org/jira/browse/IGNITE-19043
> * And I've also enabled inMemoryNodeFullPartitionRestart(that was disabled
> with https://issues.apache.org/jira/browse/IGNITE-18822) because the problem
> was probably fixed within https://issues.apache.org/jira/browse/IGNITE-19059
> and https://issues.apache.org/jira/browse/IGNITE-19022
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19178) Add Sonar to Ignite project to analyze master and release branches
Maxim Muzafarov created IGNITE-19178: Summary: Add Sonar to Ignite project to analyze master and release branches Key: IGNITE-19178 URL: https://issues.apache.org/jira/browse/IGNITE-19178 Project: Ignite Issue Type: Task Components: build Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.16 Sonar is a code quality and security tool that is free to open-source projects and recommended by the INFRA team the link for documentation: https://cwiki.apache.org/confluence/display/INFRA/SonarCloud+for+ASF+projects Despite in commonly used by many of the ASF projects, it can have the following benefits for us: - visualise simple problems for newcomers to work on; - see the trends in the source code; - add an extra layer of static code analysis; The INFRA ticket: https://issues.apache.org/jira/browse/INFRA-24415 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19127) Sql. Custom data types. Fix type inference in the presence of nullable types.
[ https://issues.apache.org/jira/browse/IGNITE-19127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-19127: Labels: calcite3-required ignite-3 (was: ignite-3) > Sql. Custom data types. Fix type inference in the presence of nullable types. > - > > Key: IGNITE-19127 > URL: https://issues.apache.org/jira/browse/IGNITE-19127 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > > Nullable types are least restrictive than non-nullable types. This is not > true for custom data types and should be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19127) Sql. Custom data types. Fix type inference in the presence of nullable types.
[ https://issues.apache.org/jira/browse/IGNITE-19127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-19127: Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Custom data types. Fix type inference in the presence of nullable types. > - > > Key: IGNITE-19127 > URL: https://issues.apache.org/jira/browse/IGNITE-19127 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Nullable types are least restrictive than non-nullable types. This is not > true for custom data types and should be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19172) Fix TODOs for closed issues
[ https://issues.apache.org/jira/browse/IGNITE-19172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-19172: -- Assignee: Ivan Bessonov > Fix TODOs for closed issues > --- > > Key: IGNITE-19172 > URL: https://issues.apache.org/jira/browse/IGNITE-19172 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > https://issues.apache.org/jira/browse/IGNITE-14496 > https://issues.apache.org/jira/browse/IGNITE-17083 > https://issues.apache.org/jira/browse/IGNITE-16835 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19120) Raft client should get leader metadata along while getting leader itself
[ https://issues.apache.org/jira/browse/IGNITE-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-19120: -- Description: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. *Definition of done* readIndex call is removed from Replica#waitForActualState. RaftGroupServiceImpl#refreshAndGetLeaderWithTerm also gets leader metadata along with leader. LeaderWithTerm class is enriched with metadata and (possibly) renamed. was: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. *Definition of done* readIndex call is removed from Replica#waitForActualState. > Raft client should get leader metadata along while getting leader itself > > > Key: IGNITE-19120 > URL: https://issues.apache.org/jira/browse/IGNITE-19120 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > This ticket is about TopologyAwareRaftGroupService which can subscribe on > leader change, and RaftGroupService methods such as > refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in > leader's storage. > This will allow to remove readIndex requests on acceptance of a lease on > leaseholder candidate. As we know that no write commands in replication group > can happen in absence of leaseholder, this means that leaseholder should just > catch up leader's last applied index received with leader metadata to make > sure that its local storage is up-to-date. > *Definition of done* > readIndex call is removed from Replica#waitForActualState. > RaftGroupServiceImpl#refreshAndGetLeaderWithTerm also gets leader metadata > along with leader. > LeaderWithTerm class is enriched with metadata and (possibly) renamed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18320) [IEP-94] Reimplement cache scan command to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-18320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-18320: -- Assignee: Aleksey Plekhanov > [IEP-94] Reimplement cache scan command to control.sh > - > > Key: IGNITE-18320 > URL: https://issues.apache.org/jira/browse/IGNITE-18320 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Aleksey Plekhanov >Priority: Blocker > Labels: IEP-94 > Fix For: 2.15 > > > To decomission ignitevisorcmd.sh we need to move all useful commands to > control script. > > Cache scan command is used by users to view cache content so we must provide > it via control.sh -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19120) Raft client should get leader metadata along while getting leader itself
[ https://issues.apache.org/jira/browse/IGNITE-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-19120: -- Description: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. *Definition of done* readIndex call is removed from Replica#waitForActualState. was: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. Definition of done readIndex call is removed from Replica#waitForActualState. > Raft client should get leader metadata along while getting leader itself > > > Key: IGNITE-19120 > URL: https://issues.apache.org/jira/browse/IGNITE-19120 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > This ticket is about TopologyAwareRaftGroupService which can subscribe on > leader change, and RaftGroupService methods such as > refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in > leader's storage. > This will allow to remove readIndex requests on acceptance of a lease on > leaseholder candidate. As we know that no write commands in replication group > can happen in absence of leaseholder, this means that leaseholder should just > catch up leader's last applied index received with leader metadata to make > sure that its local storage is up-to-date. > *Definition of done* > readIndex call is removed from Replica#waitForActualState. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19120) Raft client should get leader metadata along while getting leader itself
[ https://issues.apache.org/jira/browse/IGNITE-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-19120: -- Description: *Motivation* This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. Definition of done readIndex call is removed from Replica#waitForActualState. was: This ticket is about TopologyAwareRaftGroupService which can subscribe on leader change, and RaftGroupService methods such as refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in leader's storage. This will allow to remove readIndex requests on acceptance of a lease on leaseholder candidate. As we know that no write commands in replication group can happen in absence of leaseholder, this means that leaseholder should just catch up leader's last applied index received with leader metadata to make sure that its local storage is up-to-date. > Raft client should get leader metadata along while getting leader itself > > > Key: IGNITE-19120 > URL: https://issues.apache.org/jira/browse/IGNITE-19120 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > This ticket is about TopologyAwareRaftGroupService which can subscribe on > leader change, and RaftGroupService methods such as > refreshAndGetLeaderWithTerm(). Necessary metadata is last applied index in > leader's storage. > This will allow to remove readIndex requests on acceptance of a lease on > leaseholder candidate. As we know that no write commands in replication group > can happen in absence of leaseholder, this means that leaseholder should just > catch up leader's last applied index received with leader metadata to make > sure that its local storage is up-to-date. > Definition of done > readIndex call is removed from Replica#waitForActualState. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16985) Design table management flow (part 1)
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707222#comment-17707222 ] Denis Chudov commented on IGNITE-16985: --- Things that require attention: 1. The contract of #update(token, updater) is violated in createTableLocally and updateAssignmentsInternal: update operation in updateAssignmentsInternal is not commutative 2. PartitionReplicaListener should be created by ReplicaManager. In TableManager it is created only to pass to to #startReplica method, meanwhile it requires additional fields and thread pools in TableManager. 3. tableManager.tableAsync in tablesVv.update in SqlSchemaManager: possibly should be replaced to #get(token). Also, it leads to possible race with table creation: API future is done before calciteSchemaVv is completed. 4. tablesByIdVv.get(evt.revision()) : potential OutdatedTokenException in case when metastorage watch processing gets significantly behind configuration updates. > Design table management flow (part 1) > - > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Attachments: VersionedValuesUpdates.svg, VersionedValuesUpdates.yuml, > onTableCreate.svg, onTableCreate.yuml, onTableDrop.svg, onTableDrop.yuml, > table.svg, table.yuml > > > As a part of the issue planed: > # Draw a time diagram of all operations: createTable(), dropTable(), > table(), tables(). > # Emphases of correctness work of causality tokens: tablesByIdVv. > # Reflect cross components interactions. Components: Schema manager, SQL > manager (SqlQueryProcessor), Affinity manager (it is not dedicated for now). > > The task for this ticket is to make a detailed diagram of the current flow, > to ease the design itself. > Definition of done: > We have detailed and clear description of table manager flows and the ticket > IGNITE-18989 is enriched with details about the flaws we want to fix. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19175) [ducktests] Add logging support to NONE service type
[ https://issues.apache.org/jira/browse/IGNITE-19175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707218#comment-17707218 ] Ivan Daschinsky commented on IGNITE-19175: -- [~serge.korotkov] Many thanks for review, merged > [ducktests] Add logging support to NONE service type > > > Key: IGNITE-19175 > URL: https://issues.apache.org/jira/browse/IGNITE-19175 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19175) [ducktests] Add logging support to NONE service type
[ https://issues.apache.org/jira/browse/IGNITE-19175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-19175: - Fix Version/s: 2.15 > [ducktests] Add logging support to NONE service type > > > Key: IGNITE-19175 > URL: https://issues.apache.org/jira/browse/IGNITE-19175 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Labels: ducktests > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16985) Design table management flow (part 1)
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-16985: -- Attachment: table.svg onTableDrop.svg VersionedValuesUpdates.svg onTableCreate.svg > Design table management flow (part 1) > - > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Attachments: VersionedValuesUpdates.svg, VersionedValuesUpdates.yuml, > onTableCreate.svg, onTableCreate.yuml, onTableDrop.svg, onTableDrop.yuml, > table.svg, table.yuml > > > As a part of the issue planed: > # Draw a time diagram of all operations: createTable(), dropTable(), > table(), tables(). > # Emphases of correctness work of causality tokens: tablesByIdVv. > # Reflect cross components interactions. Components: Schema manager, SQL > manager (SqlQueryProcessor), Affinity manager (it is not dedicated for now). > > The task for this ticket is to make a detailed diagram of the current flow, > to ease the design itself. > Definition of done: > We have detailed and clear description of table manager flows and the ticket > IGNITE-18989 is enriched with details about the flaws we want to fix. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16985) Design table management flow (part 1)
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-16985: -- Attachment: table.yuml onTableDrop.yuml VersionedValuesUpdates.yuml onTableCreate.yuml > Design table management flow (part 1) > - > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Attachments: VersionedValuesUpdates.svg, VersionedValuesUpdates.yuml, > onTableCreate.svg, onTableCreate.yuml, onTableDrop.svg, onTableDrop.yuml, > table.svg, table.yuml > > > As a part of the issue planed: > # Draw a time diagram of all operations: createTable(), dropTable(), > table(), tables(). > # Emphases of correctness work of causality tokens: tablesByIdVv. > # Reflect cross components interactions. Components: Schema manager, SQL > manager (SqlQueryProcessor), Affinity manager (it is not dedicated for now). > > The task for this ticket is to make a detailed diagram of the current flow, > to ease the design itself. > Definition of done: > We have detailed and clear description of table manager flows and the ticket > IGNITE-18989 is enriched with details about the flaws we want to fix. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19177) Add assignments checks when building indexes
Kirill Tkalenko created IGNITE-19177: Summary: Add assignments checks when building indexes Key: IGNITE-19177 URL: https://issues.apache.org/jira/browse/IGNITE-19177 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 To simplify the implementation of the mechanism for building indexes, I deliberately did not add a check on the assignment of a node to a partition. Since getting the leader and checking if I am the leader for the partition is a simpler code. In the future, it would be useful to add an assignment check after the implementation of the new rebalancing mechanism. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18999) Snapshot only primary copies of partitions
[ https://issues.apache.org/jira/browse/IGNITE-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-18999: - Fix Version/s: 2.15 > Snapshot only primary copies of partitions > -- > > Key: IGNITE-18999 > URL: https://issues.apache.org/jira/browse/IGNITE-18999 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-43, ise > Fix For: 2.15 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Ignite must provide an option to snapshot only primary copies of partitions. > This will improve: > * snapshot creation time. > * disk usage during snapshot creation. > * space amount to store snapshot. > This will lead to the following disadvantages during restore process: > * rebalance (can be omitted with custom file copy script and cellular > affinity) > * index.bin rebuild - performance improved in IGNITE-18271 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19176) Sql. Unexpected DML results with explicit TX and single column table.
Pavel Pereslegin created IGNITE-19176:
-
Summary: Sql. Unexpected DML results with explicit TX and single
column table.
Key: IGNITE-19176
URL: https://issues.apache.org/jira/browse/IGNITE-19176
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
When we try to insert values into a single column table using explicit
transaction, those values are not visible in the same transaction.
Example
{code:java}
create table test(id int primary key) // single column table
{code}
{code:java}
// case 1
start explicit tx
insert into test values (0), (1)
select count(*) from test // returns 0 instead of 2
finish tx{code}
{code:java}
// case 2
start explicit tx
insert into test values (0), (1)
commit tx
start explicit tx
select count(*) from test // returns 0 instead of 2
finish tx{code}
If we do this using implicit transaction - all works fine.
If we add a column to the table, everything will work fine.
Reproducer
{code:java}
@Test
public void test() {
sql("CREATE TABLE myTbl (id INT PRIMARY KEY) WITH REPLICAS=2,
PARTITIONS=10");
Ignite ignite = CLUSTER_NODES.get(0);
ignite.transactions().runInTransaction(tx -> {
sql(tx, "INSERT INTO myTbl VALUES (0), (1)");
List> rows = sql(tx, "SELECT count(*) from myTbl");
assertEquals(2L, rows.get(0).get(0));
});
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19125) Sql. Expected errors on joins are not rised after bump calcite version to 1.34
[
https://issues.apache.org/jira/browse/IGNITE-19125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19125:
Description:
After version was bumped [1], some expected errors are not rised:
/join/inner/test_using_join.test_ignore
{noformat}
statement error
SELECT * FROM t1 JOIN t2 USING(a) JOIN t2 t2b USING (b);
# this is the same, but now with a duplicate potential binding on the RHS
statement error
select * from (values (1)) tbl(i) join ((values (1)) tbl2(i) join (values (1))
tbl3(i) on tbl2.i=tbl3.i) using (i)
{noformat}
In caclite 1.32 it works properly well. Probably it was broken by [2]
[1] https://issues.apache.org/jira/browse/IGNITE-18752
[2] https://issues.apache.org/jira/browse/CALCITE-5253
was:
After version was bumped [1], some expected errors are not rised:
/join/inner/test_using_join.test_ignore
{noformat}
statement error
SELECT * FROM t1 JOIN t2 USING(a) JOIN t2 t2b USING (b);
# this is the same, but now with a duplicate potential binding on the RHS
statement error
select * from (values (1)) tbl(i) join ((values (1)) tbl2(i) join (values (1))
tbl3(i) on tbl2.i=tbl3.i) using (i)
{noformat}
In caclite 1.32 it works properly well.
[1] https://issues.apache.org/jira/browse/IGNITE-18752
> Sql. Expected errors on joins are not rised after bump calcite version to 1.34
> --
>
> Key: IGNITE-19125
> URL: https://issues.apache.org/jira/browse/IGNITE-19125
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite3-required, ignite-3
>
> After version was bumped [1], some expected errors are not rised:
> /join/inner/test_using_join.test_ignore
> {noformat}
> statement error
> SELECT * FROM t1 JOIN t2 USING(a) JOIN t2 t2b USING (b);
> # this is the same, but now with a duplicate potential binding on the RHS
> statement error
> select * from (values (1)) tbl(i) join ((values (1)) tbl2(i) join (values
> (1)) tbl3(i) on tbl2.i=tbl3.i) using (i)
> {noformat}
> In caclite 1.32 it works properly well. Probably it was broken by [2]
> [1] https://issues.apache.org/jira/browse/IGNITE-18752
> [2] https://issues.apache.org/jira/browse/CALCITE-5253
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19141) Node failes on rebalance during deactivation
[
https://issues.apache.org/jira/browse/IGNITE-19141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707164#comment-17707164
]
Aleksey Plekhanov commented on IGNITE-19141:
Node.js thin client failure related to some type of infrastructure problems
(thin clients not affected anyhow by this patch):
{noformat}
Missing write access to
/data/tcAgent/work/7a5058913152b6a6/ignite-nodejs-thin-client/node_modules/apache-ignite-client{noformat}
> Node failes on rebalance during deactivation
>
>
> Key: IGNITE-19141
> URL: https://issues.apache.org/jira/browse/IGNITE-19141
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failure handler triggered if caches is stopped (for example, due to
> deactivation) and node is processing partitions supply message. Reproducer:
> {code:java}
> @Override protected FailureHandler getFailureHandler(String
> igniteInstanceName) {
> return new StopNodeFailureHandler();
> }
> @Test
> public void testRebalanceOnDeactivate() throws Exception {
> IgniteEx ignite0 = startGrid(0);
> IgniteEx ignite1 = startGrid(1);
> ignite0.cluster().state(ClusterState.ACTIVE);
> ignite0.cluster().baselineAutoAdjustEnabled(false);
> for (int i = 0; i < 10; i++) {
> IgniteCache cache = ignite0.getOrCreateCache(
> new CacheConfiguration Integer>(DEFAULT_CACHE_NAME).setBackups(1)
> .setAffinity(new RendezvousAffinityFunction(false, 2)));
> cache.clear();
> stopGrid(0);
> try (IgniteDataStreamer streamer =
> ignite1.dataStreamer(DEFAULT_CACHE_NAME)) {
> for (int j = 0; j < 100_000; j++)
> streamer.addData(j, j);
> }
> ignite0 = startGrid(0);
> ignite0.cluster().state(ClusterState.INACTIVE);
> ignite0.cluster().state(ClusterState.ACTIVE);
> }
> }{code}
> Fails with:
> {noformat}
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:447)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:584)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleSupplyMessage$0(GridDhtPreloader.java:346)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19141) Node failes on rebalance during deactivation
[
https://issues.apache.org/jira/browse/IGNITE-19141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707162#comment-17707162
]
Ignite TC Bot commented on IGNITE-19141:
{panel:title=Branch: [pull/10613/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=7117745]]
{panel}
{panel:title=Branch: [pull/10613/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=7113837]]
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnCacheStop[sharedGroup=false,
persistence=false] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnCacheStop[sharedGroup=true,
persistence=false] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnDeactivate[sharedGroup=false,
persistence=true] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnCacheStop[sharedGroup=false,
persistence=true] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnDeactivate[sharedGroup=false,
persistence=false] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnDeactivate[sharedGroup=true,
persistence=true] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnCacheStop[sharedGroup=true,
persistence=true] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
IgniteRebalanceRepeatingCacheStopTest.testRebalanceOnDeactivate[sharedGroup=true,
persistence=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7111800buildTypeId=IgniteTests24Java8_RunAll]
> Node failes on rebalance during deactivation
>
>
> Key: IGNITE-19141
> URL: https://issues.apache.org/jira/browse/IGNITE-19141
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failure handler triggered if caches is stopped (for example, due to
> deactivation) and node is processing partitions supply message. Reproducer:
> {code:java}
> @Override protected FailureHandler getFailureHandler(String
> igniteInstanceName) {
> return new StopNodeFailureHandler();
> }
> @Test
> public void testRebalanceOnDeactivate() throws Exception {
> IgniteEx ignite0 = startGrid(0);
> IgniteEx ignite1 = startGrid(1);
> ignite0.cluster().state(ClusterState.ACTIVE);
> ignite0.cluster().baselineAutoAdjustEnabled(false);
> for (int i = 0; i < 10; i++) {
> IgniteCache cache = ignite0.getOrCreateCache(
> new CacheConfiguration Integer>(DEFAULT_CACHE_NAME).setBackups(1)
> .setAffinity(new RendezvousAffinityFunction(false, 2)));
> cache.clear();
> stopGrid(0);
> try (IgniteDataStreamer streamer =
> ignite1.dataStreamer(DEFAULT_CACHE_NAME)) {
> for (int j = 0; j < 100_000; j++)
> streamer.addData(j, j);
> }
> ignite0 = startGrid(0);
> ignite0.cluster().state(ClusterState.INACTIVE);
> ignite0.cluster().state(ClusterState.ACTIVE);
> }
> }{code}
> Fails with:
> {noformat}
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:447)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:584)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleSupplyMessage$0(GridDhtPreloader.java:346)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19111) Storage corruption if pages changed after last checkpoint during deactivation
[
https://issues.apache.org/jira/browse/IGNITE-19111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707161#comment-17707161
]
Ignite TC Bot commented on IGNITE-19111:
{panel:title=Branch: [pull/10615/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10615/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7116301]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IgnitePdsCheckpointAfterDeactivateTest.testCpAfterClusterDeactivate -
PASSED{color}
{color:#8b}PDS 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7116255]]
* {color:#013220}IgnitePdsTestSuite:
IgnitePdsCheckpointAfterDeactivateTest.testCpAfterClusterDeactivate -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7116304buildTypeId=IgniteTests24Java8_RunAll]
> Storage corruption if pages changed after last checkpoint during deactivation
> -
>
> Key: IGNITE-19111
> URL: https://issues.apache.org/jira/browse/IGNITE-19111
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During cluster deactivation we force checkpoint (with "caches stop" reason)
> and remove checkpoint listeners before actual caches stop. But if there are
> some activity with data pages on the node after that checkpoint, but before
> caches stops and next checkpoint is started, the storage can be corrupted.
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true))
> .setCheckpointFrequency(1_000L))
> .setFailureHandler(new StopNodeFailureHandler());
> }
> /** */
> @Test
> public void testCpAfterClusterDeactivate() throws Exception {
> IgniteEx ignite0 = startGrid(0);
> IgniteEx ignite1 = startGrid(1);
> ignite0.cluster().state(ClusterState.ACTIVE);
> ignite0.getOrCreateCache(new
> CacheConfiguration<>(DEFAULT_CACHE_NAME).setBackups(1)
> .setAffinity(new RendezvousAffinityFunction(false, 10)));
> try (IgniteDataStreamer streamer =
> ignite0.dataStreamer(DEFAULT_CACHE_NAME)) {
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i);
> }
> stopGrid(0);
> try (IgniteDataStreamer streamer =
> ignite1.dataStreamer(DEFAULT_CACHE_NAME)) {
> streamer.allowOverwrite(true);
> for (int i = 0; i < 100_000; i++)
> streamer.addData(i, i + 1);
> }
> ignite0 = startGrid(0);
>
> ((GridCacheDatabaseSharedManager)ignite0.context().cache().context().database()).addCheckpointListener(new
> CheckpointListener() {
> @Override public void onMarkCheckpointBegin(Context ctx) {
> // No-op.
> }
> @Override public void onCheckpointBegin(Context ctx) {
> if ("caches stop".equals(ctx.progress().reason()))
> doSleep(1_000L);
> }
> @Override public void beforeCheckpointBegin(Context ctx) {
> // No-op.
> }
> });
> ignite0.cluster().state(ClusterState.INACTIVE);
> doSleep(2_000L);
> ignite0.cluster().state(ClusterState.ACTIVE);
> IgniteCache cache =
> ignite0.cache(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 100_000; i++)
> assertEquals((Integer)(i + 1), cache.get(i));
> } {code}
> This reproducer shuts down the node with some probability (about 1/5 on my
> laptop) on activation or on last check with {{{}CorruptedTreeException{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19175) [ducktests] Add logging support to NONE service type
[ https://issues.apache.org/jira/browse/IGNITE-19175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-19175: - Issue Type: Test (was: Improvement) > [ducktests] Add logging support to NONE service type > > > Key: IGNITE-19175 > URL: https://issues.apache.org/jira/browse/IGNITE-19175 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19175) [ducktests] Add logging support to NONE service type
[ https://issues.apache.org/jira/browse/IGNITE-19175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-19175: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > [ducktests] Add logging support to NONE service type > > > Key: IGNITE-19175 > URL: https://issues.apache.org/jira/browse/IGNITE-19175 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19175) [ducktests] Add logging support to NONE service type
[ https://issues.apache.org/jira/browse/IGNITE-19175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-19175: - Labels: ducktests (was: ) > [ducktests] Add logging support to NONE service type > > > Key: IGNITE-19175 > URL: https://issues.apache.org/jira/browse/IGNITE-19175 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19175) [ducktests] Add logging support to NONE service type
Ivan Daschinsky created IGNITE-19175: Summary: [ducktests] Add logging support to NONE service type Key: IGNITE-19175 URL: https://issues.apache.org/jira/browse/IGNITE-19175 Project: Ignite Issue Type: Improvement Reporter: Ivan Daschinsky Assignee: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18875) Sql. Drop AbstractPlannerTest.TestTable.
[
https://issues.apache.org/jira/browse/IGNITE-18875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707146#comment-17707146
]
Gael Yimen Yimga commented on IGNITE-18875:
---
[~zstan]
Here is the PR [1]
[1]
[https://github.com/apache/ignite-3/pull/1873|https://github.com/apache/ignite-3/pull/1873]
> Sql. Drop AbstractPlannerTest.TestTable.
>
>
> Key: IGNITE-18875
> URL: https://issues.apache.org/jira/browse/IGNITE-18875
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Gael Yimen Yimga
>Priority: Major
> Labels: ignite-3, newbie, tech-debt-test
> Fix For: 3.0.0-beta2
>
>
> Use test framework for schema configuration in tests.
> Replace
> {code:java}
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.TestTable
> {code}
> with
> {code:java}
> org.apache.ignite.internal.sql.engine.framework.TestTable
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18875) Sql. Drop AbstractPlannerTest.TestTable.
[
https://issues.apache.org/jira/browse/IGNITE-18875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707142#comment-17707142
]
Evgeny Stanilovsky edited comment on IGNITE-18875 at 3/31/23 6:26 AM:
--
[~yimengael] thanks for your effort, where can i found your PR ? You can link
your PR for example like [1]
TC , just register new acc: https://ci.ignite.apache.org/registerUser.html
[1] https://issues.apache.org/jira/browse/IGNITE-18442
was (Author: zstan):
[~yimengael] thanks for your effort, where can i found your PR ? You can link
your PR for example like [1]
TC access in progress.
[1] https://issues.apache.org/jira/browse/IGNITE-18442
> Sql. Drop AbstractPlannerTest.TestTable.
>
>
> Key: IGNITE-18875
> URL: https://issues.apache.org/jira/browse/IGNITE-18875
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Gael Yimen Yimga
>Priority: Major
> Labels: ignite-3, newbie, tech-debt-test
> Fix For: 3.0.0-beta2
>
>
> Use test framework for schema configuration in tests.
> Replace
> {code:java}
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.TestTable
> {code}
> with
> {code:java}
> org.apache.ignite.internal.sql.engine.framework.TestTable
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18875) Sql. Drop AbstractPlannerTest.TestTable.
[
https://issues.apache.org/jira/browse/IGNITE-18875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707142#comment-17707142
]
Evgeny Stanilovsky commented on IGNITE-18875:
-
[~yimengael] thanks for your effort, where can i found your PR ? You can link
your PR for example like [1]
TC access in progress.
[1] https://issues.apache.org/jira/browse/IGNITE-18442
> Sql. Drop AbstractPlannerTest.TestTable.
>
>
> Key: IGNITE-18875
> URL: https://issues.apache.org/jira/browse/IGNITE-18875
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Gael Yimen Yimga
>Priority: Major
> Labels: ignite-3, newbie, tech-debt-test
> Fix For: 3.0.0-beta2
>
>
> Use test framework for schema configuration in tests.
> Replace
> {code:java}
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.TestTable
> {code}
> with
> {code:java}
> org.apache.ignite.internal.sql.engine.framework.TestTable
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19169) Deadlock detected while calling MvPartitionStorage#pollForVacuum
[
https://issues.apache.org/jira/browse/IGNITE-19169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-19169:
-
Description:
h2. *Update:*
For now, a possible deadlock fo *MvPartitionStorage#pollForVacuum* inside
*MvPartitionStorage#runConsistently* is fine, because we need to maintain
consistency when working with indexes.
It is enough for us to fix *StorageUpdateHandler#executeBatchGc* so that it
runs outside the general *MvPartitionStorage#runConsistently* and each
*StorageUpdateHandler#internalVacuum* is in its own
*MvPartitionStorage#runConsistently*.
h2. *Problem:*
Deadlock detected while calling
*org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
reproducer:
{code:java}
@Test
public void testDeadLock() {
RowId rowId2 = new RowId(PARTITION_ID);
for (int i = 0; i < REPEATS; i++) {
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, null, clock.now());
addWriteCommitted(rowId2, null, clock.now());
RunnableX remove2rowsAction = () -> {
storage.runConsistently(() -> {
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
return null;
});
};
runRace(remove2rowsAction, remove2rowsAction);
assertNull(storage.closestRowId(RowId.lowestRowId(PARTITION_ID)));
}
}
{code}
was:
h2. *Update:*
For now, a possible deadlock fo *MvPartitionStorage#pollForVacuum* inside
*MvPartitionStorage#runConsistently* is fine, because we need to maintain
consistency when working with indexes.
It is enough for us to fix *StorageUpdateHandler#executeBatchGc* so that it
runs outside the general *MvPartitionStorage#runConsistently* and each
*StorageUpdateHandler#internalVacuum* is in its own
*MvPartitionStorage#runConsistently*.
Deadlock detected while calling
*org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
reproducer:
{code:java}
@Test
public void testDeadLock() {
RowId rowId2 = new RowId(PARTITION_ID);
for (int i = 0; i < REPEATS; i++) {
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, null, clock.now());
addWriteCommitted(rowId2, null, clock.now());
RunnableX remove2rowsAction = () -> {
storage.runConsistently(() -> {
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
return null;
});
};
runRace(remove2rowsAction, remove2rowsAction);
assertNull(storage.closestRowId(RowId.lowestRowId(PARTITION_ID)));
}
}
{code}
> Deadlock detected while calling MvPartitionStorage#pollForVacuum
>
>
> Key: IGNITE-19169
> URL: https://issues.apache.org/jira/browse/IGNITE-19169
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. *Update:*
> For now, a possible deadlock fo *MvPartitionStorage#pollForVacuum* inside
> *MvPartitionStorage#runConsistently* is fine, because we need to maintain
> consistency when working with indexes.
> It is enough for us to fix *StorageUpdateHandler#executeBatchGc* so that it
> runs outside the general *MvPartitionStorage#runConsistently* and each
> *StorageUpdateHandler#internalVacuum* is in its own
> *MvPartitionStorage#runConsistently*.
> h2. *Problem:*
> Deadlock detected while calling
> *org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
> reproducer:
> {code:java}
> @Test
> public void testDeadLock() {
> RowId rowId2 = new RowId(PARTITION_ID);
> for (int i = 0; i < REPEATS; i++) {
> addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
> addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
> addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
> addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
> addWriteCommitted(ROW_ID, null, clock.now());
> addWriteCommitted(rowId2, null, clock.now());
> RunnableX remove2rowsAction = () -> {
> storage.runConsistently(() -> {
>
[jira] [Updated] (IGNITE-19169) Deadlock detected while calling MvPartitionStorage#pollForVacuum
[
https://issues.apache.org/jira/browse/IGNITE-19169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-19169:
-
Description:
h2. *Update:*
For now, a possible deadlock fo *MvPartitionStorage#pollForVacuum* inside
*MvPartitionStorage#runConsistently* is fine, because we need to maintain
consistency when working with indexes.
It is enough for us to fix *StorageUpdateHandler#executeBatchGc* so that it
runs outside the general *MvPartitionStorage#runConsistently* and each
*StorageUpdateHandler#internalVacuum* is in its own
*MvPartitionStorage#runConsistently*.
Deadlock detected while calling
*org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
reproducer:
{code:java}
@Test
public void testDeadLock() {
RowId rowId2 = new RowId(PARTITION_ID);
for (int i = 0; i < REPEATS; i++) {
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, null, clock.now());
addWriteCommitted(rowId2, null, clock.now());
RunnableX remove2rowsAction = () -> {
storage.runConsistently(() -> {
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
return null;
});
};
runRace(remove2rowsAction, remove2rowsAction);
assertNull(storage.closestRowId(RowId.lowestRowId(PARTITION_ID)));
}
}
{code}
was:
Deadlock detected while calling
*org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
reproducer:
{code:java}
@Test
public void testDeadLock() {
RowId rowId2 = new RowId(PARTITION_ID);
for (int i = 0; i < REPEATS; i++) {
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
addWriteCommitted(ROW_ID, null, clock.now());
addWriteCommitted(rowId2, null, clock.now());
RunnableX remove2rowsAction = () -> {
storage.runConsistently(() -> {
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
return null;
});
};
runRace(remove2rowsAction, remove2rowsAction);
assertNull(storage.closestRowId(RowId.lowestRowId(PARTITION_ID)));
}
}
{code}
> Deadlock detected while calling MvPartitionStorage#pollForVacuum
>
>
> Key: IGNITE-19169
> URL: https://issues.apache.org/jira/browse/IGNITE-19169
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. *Update:*
> For now, a possible deadlock fo *MvPartitionStorage#pollForVacuum* inside
> *MvPartitionStorage#runConsistently* is fine, because we need to maintain
> consistency when working with indexes.
> It is enough for us to fix *StorageUpdateHandler#executeBatchGc* so that it
> runs outside the general *MvPartitionStorage#runConsistently* and each
> *StorageUpdateHandler#internalVacuum* is in its own
> *MvPartitionStorage#runConsistently*.
> Deadlock detected while calling
> *org.apache.ignite.internal.storage.MvPartitionStorage#pollForVacuum*,
> reproducer:
> {code:java}
> @Test
> public void testDeadLock() {
> RowId rowId2 = new RowId(PARTITION_ID);
> for (int i = 0; i < REPEATS; i++) {
> addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
> addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
> addWriteCommitted(ROW_ID, TABLE_ROW, clock.now());
> addWriteCommitted(rowId2, TABLE_ROW2, clock.now());
> addWriteCommitted(ROW_ID, null, clock.now());
> addWriteCommitted(rowId2, null, clock.now());
> RunnableX remove2rowsAction = () -> {
> storage.runConsistently(() -> {
> storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
> storage.pollForVacuum(HybridTimestamp.MAX_VALUE);
> return null;
> });
> };
> runRace(remove2rowsAction, remove2rowsAction);
> assertNull(storage.closestRowId(RowId.lowestRowId(PARTITION_ID)));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
