[jira] [Commented] (IGNITE-22335) Add assertion in async TxCleanupMessageResponse handler
[
https://issues.apache.org/jira/browse/IGNITE-22335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851116#comment-17851116
]
Vladislav Pyatkov commented on IGNITE-22335:
Merged 78a976b1129ab2039b1f1bc1e006a932a93cc293
> Add assertion in async TxCleanupMessageResponse handler
> ---
>
> Key: IGNITE-22335
> URL: https://issues.apache.org/jira/browse/IGNITE-22335
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> This code seems like we might send TxCleanupMessageResponse with nullabe
> correlationId and result, but it is not really possible.
> {code:java}
> txMessageSender.messagingService().addMessageHandler(TxMessageGroup.class,
> (msg, sender, correlationId) -> {
> if (msg instanceof TxCleanupMessageResponse && correlationId ==
> null) {
> CleanupReplicatedInfo result = ((TxCleanupMessageResponse)
> msg).result();
> if (result != null) {
> onCleanupReplicated(result);
> }
> if (msg instanceof TxCleanupMessageErrorResponse) {
> TxCleanupMessageErrorResponse response =
> (TxCleanupMessageErrorResponse) msg;
> LOG.warn("Exception happened during transaction cleanup
> [txId={}].", response.throwable(), response.txId());
> }
> }
> });
> {code}
> h3. Definition of done
> It just a possible siple improvment (but even better to change the responce
> inheratence structure, as the TxCleanupMessageErrorResponse does not inherit
> from TxCleanupMessageResponse):
> {code:java}
> txMessageSender.messagingService().addMessageHandler(TxMessageGroup.class,
> (msg, sender, correlationId) -> {
> if (msg instanceof TxCleanupMessageResponse && correlationId ==
> null) {
> CleanupReplicatedInfo result = ((TxCleanupMessageResponse)
> msg).result();
> if (msg instanceof TxCleanupMessageErrorResponse) {
> TxCleanupMessageErrorResponse response =
> (TxCleanupMessageErrorResponse) msg;
> LOG.warn("Exception happened during transaction cleanup
> [txId={}].", response.throwable(), response.txId());
> }
> assert result != null : "Result for the cleanup response
> cannot be null.";
> onCleanupReplicated(result);
> }
> });
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[ https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22381: --- Labels: ise (was: ) > Extensions: Broken compilation by java8, java11 > > > Key: IGNITE-22381 > URL: https://issues.apache.org/jira/browse/IGNITE-22381 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > > Compilation on java8 is broken by IGNITE-21679 > Compilation on java11 is broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22386) Many usages of wrong revision serialization in metastorage commands
[
https://issues.apache.org/jira/browse/IGNITE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-22386:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Many usages of wrong revision serialization in metastorage commands
> ---
>
> Key: IGNITE-22386
> URL: https://issues.apache.org/jira/browse/IGNITE-22386
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {code:java}
> byte[] revisionBytes = ByteUtils.longToBytes(revision);
> Iif iif = iif(
> notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
> {code}
> Code above has a bug - "longToBytes" is not a suitable serialization format
> for preserving natural comparison order used in "lt". We must fix it, because
> it leads to occasional false-positive and false-negative condition evaluation
> It also leads to flaky tests, obviously
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22386) Many usages of wrong revision serialization in metastorage commands
[
https://issues.apache.org/jira/browse/IGNITE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851039#comment-17851039
]
Roman Puchkovskiy commented on IGNITE-22386:
The patch looks good to me
> Many usages of wrong revision serialization in metastorage commands
> ---
>
> Key: IGNITE-22386
> URL: https://issues.apache.org/jira/browse/IGNITE-22386
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {code:java}
> byte[] revisionBytes = ByteUtils.longToBytes(revision);
> Iif iif = iif(
> notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
> {code}
> Code above has a bug - "longToBytes" is not a suitable serialization format
> for preserving natural comparison order used in "lt". We must fix it, because
> it leads to occasional false-positive and false-negative condition evaluation
> It also leads to flaky tests, obviously
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22387) Fix restart-partitions CLI unit tests
[ https://issues.apache.org/jira/browse/IGNITE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-22387: - Fix Version/s: 3.0.0-beta2 > Fix restart-partitions CLI unit tests > - > > Key: IGNITE-22387 > URL: https://issues.apache.org/jira/browse/IGNITE-22387 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Tests use hardcoded names of options, so failed after the change of > CLUSTER_URL_OPTION. Tests should use constants values instead of hardcode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22272) Rework Catalog API
[
https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin reassigned IGNITE-22272:
--
Assignee: Mikhail Pochatkin
> Rework Catalog API
> --
>
> Key: IGNITE-22272
> URL: https://issues.apache.org/jira/browse/IGNITE-22272
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Mikhail Pochatkin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> * Do not return a Query that has to be executed, run it immediately. For
> example: *Table table = catalog.createTable(Pojo.class)*
> * All methods should be async-first
> * Rename *create* to *createTable* (recordClass and KV methods)
> * all *createTable* methods should return a {*}Table{*}. Especially
> important for record and KV cases, where the resulting name is not obvious
> * add option to specify column/index order in builders, annotations -
> explicit order or implicit "default" (in case of composite index, colocation
> columns)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22274) Remove o.a.i.catalog.Options
[ https://issues.apache.org/jira/browse/IGNITE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-22274: -- Assignee: Mikhail Pochatkin > Remove o.a.i.catalog.Options > > > Key: IGNITE-22274 > URL: https://issues.apache.org/jira/browse/IGNITE-22274 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *org.apache.ignite.catalog.Options* affects generated SQL, but it provides no > value to the user. SQL is an implementation detail of Catalog API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22390) Sql. Cursor::requestNextAsync returns stale results
[
https://issues.apache.org/jira/browse/IGNITE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov resolved IGNITE-22390.
---
Resolution: Invalid
> Sql. Cursor::requestNextAsync returns stale results
> ---
>
> Key: IGNITE-22390
> URL: https://issues.apache.org/jira/browse/IGNITE-22390
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> The following test case begun to fail after (Sql. Avoid starting transaction
> for KV operation) [ https://issues.apache.org/jira/browse/IGNITE-22263 ]
>
> {code:java}
> package org.apache.ignite.internal.sql.engine;
> import static
> org.apache.ignite.internal.catalog.CatalogService.DEFAULT_STORAGE_PROFILE;
> import static org.apache.ignite.internal.lang.IgniteStringFormatter.format;
> import static org.apache.ignite.internal.testframework.IgniteTestUtils.await;
> import static org.junit.jupiter.api.Assertions.assertEquals;
> import java.util.Objects;
> import org.apache.ignite.internal.app.IgniteImpl;
> import org.apache.ignite.internal.sql.BaseSqlIntegrationTest;
> import org.apache.ignite.internal.sql.engine.property.SqlProperties;
> import org.apache.ignite.internal.sql.engine.property.SqlPropertiesHelper;
> import org.apache.ignite.internal.tx.HybridTimestampTracker;
> import org.apache.ignite.internal.util.AsyncCursor.BatchedResult;
> import org.gridgain.internal.security.context.GridGainSecurity;
> import org.gridgain.internal.security.context.SecurityContext;
> import org.junit.jupiter.api.Test;
> public class ItCursor extends BaseSqlIntegrationTest {
> @Override
> protected int initialNodes() {
> return 1;
> }
> @Test
> public void testCursor() {
> int rowsCount = 2000;
> sql("create zone test_zone with partitions=1, replicas=1,
> storage_profiles='" + DEFAULT_STORAGE_PROFILE + "'");
> sql("create table T (ID INT PRIMARY KEY, VAL INT) with
> primary_zone='TEST_ZONE'");
> sql(format("insert into T select X, X from table(system_range(1,
> {}))", rowsCount));
> String selectAll = "select * from T";
> AsyncSqlCursor cursor1 = openSqlCursor(selectAll);
> await(cursor1.onFirstPageReady());
> BatchedResult f =
> await(cursor1.requestNextAsync(1000));
> assertEquals(1000, f.items().size()); // f.items().size() is zero
> }
>
> private AsyncSqlCursor openSqlCursor(String sql) {
> IgniteImpl node = CLUSTER.node(0);
> SqlQueryProcessor qryProc = (SqlQueryProcessor) node.queryEngine();
> SqlProperties props = SqlPropertiesHelper.emptyProperties();
> SecurityContext securityCtx = GridGainSecurity.systemContext();
> return Objects.requireNonNull(await(qryProc.queryAsync(props, new
> HybridTimestampTracker(), null, sql, securityCtx)));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22335) Add assertion in async TxCleanupMessageResponse handler
[
https://issues.apache.org/jira/browse/IGNITE-22335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-22335:
--
Assignee: Kirill Sizov
> Add assertion in async TxCleanupMessageResponse handler
> ---
>
> Key: IGNITE-22335
> URL: https://issues.apache.org/jira/browse/IGNITE-22335
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> This code seems like we might send TxCleanupMessageResponse with nullabe
> correlationId and result, but it is not really possible.
> {code:java}
> txMessageSender.messagingService().addMessageHandler(TxMessageGroup.class,
> (msg, sender, correlationId) -> {
> if (msg instanceof TxCleanupMessageResponse && correlationId ==
> null) {
> CleanupReplicatedInfo result = ((TxCleanupMessageResponse)
> msg).result();
> if (result != null) {
> onCleanupReplicated(result);
> }
> if (msg instanceof TxCleanupMessageErrorResponse) {
> TxCleanupMessageErrorResponse response =
> (TxCleanupMessageErrorResponse) msg;
> LOG.warn("Exception happened during transaction cleanup
> [txId={}].", response.throwable(), response.txId());
> }
> }
> });
> {code}
> h3. Definition of done
> It just a possible siple improvment (but even better to change the responce
> inheratence structure, as the TxCleanupMessageErrorResponse does not inherit
> from TxCleanupMessageResponse):
> {code:java}
> txMessageSender.messagingService().addMessageHandler(TxMessageGroup.class,
> (msg, sender, correlationId) -> {
> if (msg instanceof TxCleanupMessageResponse && correlationId ==
> null) {
> CleanupReplicatedInfo result = ((TxCleanupMessageResponse)
> msg).result();
> if (msg instanceof TxCleanupMessageErrorResponse) {
> TxCleanupMessageErrorResponse response =
> (TxCleanupMessageErrorResponse) msg;
> LOG.warn("Exception happened during transaction cleanup
> [txId={}].", response.throwable(), response.txId());
> }
> assert result != null : "Result for the cleanup response
> cannot be null.";
> onCleanupReplicated(result);
> }
> });
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22390) Sql. Cursor::requestNextAsync returns stale results
[
https://issues.apache.org/jira/browse/IGNITE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22390:
--
Summary: Sql. Cursor::requestNextAsync returns stale results (was: Sql.
Cursor::requestNextAsync returns no data)
> Sql. Cursor::requestNextAsync returns stale results
> ---
>
> Key: IGNITE-22390
> URL: https://issues.apache.org/jira/browse/IGNITE-22390
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> The following test case begun to fail after
> https://issues.apache.org/jira/browse/IGNITE-22263
>
> {code:java}
> package org.apache.ignite.internal.sql.engine;
> import static
> org.apache.ignite.internal.catalog.CatalogService.DEFAULT_STORAGE_PROFILE;
> import static org.apache.ignite.internal.lang.IgniteStringFormatter.format;
> import static org.apache.ignite.internal.testframework.IgniteTestUtils.await;
> import static org.junit.jupiter.api.Assertions.assertEquals;
> import java.util.Objects;
> import org.apache.ignite.internal.app.IgniteImpl;
> import org.apache.ignite.internal.sql.BaseSqlIntegrationTest;
> import org.apache.ignite.internal.sql.engine.property.SqlProperties;
> import org.apache.ignite.internal.sql.engine.property.SqlPropertiesHelper;
> import org.apache.ignite.internal.tx.HybridTimestampTracker;
> import org.apache.ignite.internal.util.AsyncCursor.BatchedResult;
> import org.gridgain.internal.security.context.GridGainSecurity;
> import org.gridgain.internal.security.context.SecurityContext;
> import org.junit.jupiter.api.Test;
> public class ItCursor extends BaseSqlIntegrationTest {
> @Override
> protected int initialNodes() {
> return 1;
> }
> @Test
> public void testCursor() {
> int rowsCount = 2000;
> sql("create zone test_zone with partitions=1, replicas=1,
> storage_profiles='" + DEFAULT_STORAGE_PROFILE + "'");
> sql("create table T (ID INT PRIMARY KEY, VAL INT) with
> primary_zone='TEST_ZONE'");
> sql(format("insert into T select X, X from table(system_range(1,
> {}))", rowsCount));
> String selectAll = "select * from T";
> AsyncSqlCursor cursor1 = openSqlCursor(selectAll);
> await(cursor1.onFirstPageReady());
> BatchedResult f =
> await(cursor1.requestNextAsync(1000));
> assertEquals(1000, f.items().size()); // f.items().size() is zero
> }
>
> private AsyncSqlCursor openSqlCursor(String sql) {
> IgniteImpl node = CLUSTER.node(0);
> SqlQueryProcessor qryProc = (SqlQueryProcessor) node.queryEngine();
> SqlProperties props = SqlPropertiesHelper.emptyProperties();
> SecurityContext securityCtx = GridGainSecurity.systemContext();
> return Objects.requireNonNull(await(qryProc.queryAsync(props, new
> HybridTimestampTracker(), null, sql, securityCtx)));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22390) Sql. Cursor::requestNextAsync returns stale results
[
https://issues.apache.org/jira/browse/IGNITE-22390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22390:
--
Description:
The following test case begun to fail after (Sql. Avoid starting transaction
for KV operation) [ https://issues.apache.org/jira/browse/IGNITE-22263 ]
{code:java}
package org.apache.ignite.internal.sql.engine;
import static
org.apache.ignite.internal.catalog.CatalogService.DEFAULT_STORAGE_PROFILE;
import static org.apache.ignite.internal.lang.IgniteStringFormatter.format;
import static org.apache.ignite.internal.testframework.IgniteTestUtils.await;
import static org.junit.jupiter.api.Assertions.assertEquals;
import java.util.Objects;
import org.apache.ignite.internal.app.IgniteImpl;
import org.apache.ignite.internal.sql.BaseSqlIntegrationTest;
import org.apache.ignite.internal.sql.engine.property.SqlProperties;
import org.apache.ignite.internal.sql.engine.property.SqlPropertiesHelper;
import org.apache.ignite.internal.tx.HybridTimestampTracker;
import org.apache.ignite.internal.util.AsyncCursor.BatchedResult;
import org.gridgain.internal.security.context.GridGainSecurity;
import org.gridgain.internal.security.context.SecurityContext;
import org.junit.jupiter.api.Test;
public class ItCursor extends BaseSqlIntegrationTest {
@Override
protected int initialNodes() {
return 1;
}
@Test
public void testCursor() {
int rowsCount = 2000;
sql("create zone test_zone with partitions=1, replicas=1,
storage_profiles='" + DEFAULT_STORAGE_PROFILE + "'");
sql("create table T (ID INT PRIMARY KEY, VAL INT) with
primary_zone='TEST_ZONE'");
sql(format("insert into T select X, X from table(system_range(1, {}))",
rowsCount));
String selectAll = "select * from T";
AsyncSqlCursor cursor1 = openSqlCursor(selectAll);
await(cursor1.onFirstPageReady());
BatchedResult f = await(cursor1.requestNextAsync(1000));
assertEquals(1000, f.items().size()); // f.items().size() is zero
}
private AsyncSqlCursor openSqlCursor(String sql) {
IgniteImpl node = CLUSTER.node(0);
SqlQueryProcessor qryProc = (SqlQueryProcessor) node.queryEngine();
SqlProperties props = SqlPropertiesHelper.emptyProperties();
SecurityContext securityCtx = GridGainSecurity.systemContext();
return Objects.requireNonNull(await(qryProc.queryAsync(props, new
HybridTimestampTracker(), null, sql, securityCtx)));
}
}
{code}
was:
The following test case begun to fail after
https://issues.apache.org/jira/browse/IGNITE-22263
{code:java}
package org.apache.ignite.internal.sql.engine;
import static
org.apache.ignite.internal.catalog.CatalogService.DEFAULT_STORAGE_PROFILE;
import static org.apache.ignite.internal.lang.IgniteStringFormatter.format;
import static org.apache.ignite.internal.testframework.IgniteTestUtils.await;
import static org.junit.jupiter.api.Assertions.assertEquals;
import java.util.Objects;
import org.apache.ignite.internal.app.IgniteImpl;
import org.apache.ignite.internal.sql.BaseSqlIntegrationTest;
import org.apache.ignite.internal.sql.engine.property.SqlProperties;
import org.apache.ignite.internal.sql.engine.property.SqlPropertiesHelper;
import org.apache.ignite.internal.tx.HybridTimestampTracker;
import org.apache.ignite.internal.util.AsyncCursor.BatchedResult;
import org.gridgain.internal.security.context.GridGainSecurity;
import org.gridgain.internal.security.context.SecurityContext;
import org.junit.jupiter.api.Test;
public class ItCursor extends BaseSqlIntegrationTest {
@Override
protected int initialNodes() {
return 1;
}
@Test
public void testCursor() {
int rowsCount = 2000;
sql("create zone test_zone with partitions=1, replicas=1,
storage_profiles='" + DEFAULT_STORAGE_PROFILE + "'");
sql("create table T (ID INT PRIMARY KEY, VAL INT) with
primary_zone='TEST_ZONE'");
sql(format("insert into T select X, X from table(system_range(1, {}))",
rowsCount));
String selectAll = "select * from T";
AsyncSqlCursor cursor1 = openSqlCursor(selectAll);
await(cursor1.onFirstPageReady());
BatchedResult f = await(cursor1.requestNextAsync(1000));
assertEquals(1000, f.items().size()); // f.items().size() is zero
}
private AsyncSqlCursor openSqlCursor(String sql) {
IgniteImpl node = CLUSTER.node(0);
SqlQueryProcessor qryProc = (SqlQueryProcessor) node.queryEngine();
SqlProperties props = SqlPropertiesHelper.emptyProperties();
SecurityContext securityCtx = GridGainSecurity.systemContext();
return Objects.requireNonNull(await(qryProc.queryAsync(props, new
HybridTimestampTracker(), null, sql, securityCtx)));
}
}
{code}
> Sql. Cursor::requestNextAsync returns stale results
>
[jira] [Created] (IGNITE-22390) Sql. Cursor::requestNextAsync returns no data
Maksim Zhuravkov created IGNITE-22390:
-
Summary: Sql. Cursor::requestNextAsync returns no data
Key: IGNITE-22390
URL: https://issues.apache.org/jira/browse/IGNITE-22390
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
The following test case begun to fail after
https://issues.apache.org/jira/browse/IGNITE-22263
{code:java}
package org.apache.ignite.internal.sql.engine;
import static
org.apache.ignite.internal.catalog.CatalogService.DEFAULT_STORAGE_PROFILE;
import static org.apache.ignite.internal.lang.IgniteStringFormatter.format;
import static org.apache.ignite.internal.testframework.IgniteTestUtils.await;
import static org.junit.jupiter.api.Assertions.assertEquals;
import java.util.Objects;
import org.apache.ignite.internal.app.IgniteImpl;
import org.apache.ignite.internal.sql.BaseSqlIntegrationTest;
import org.apache.ignite.internal.sql.engine.property.SqlProperties;
import org.apache.ignite.internal.sql.engine.property.SqlPropertiesHelper;
import org.apache.ignite.internal.tx.HybridTimestampTracker;
import org.apache.ignite.internal.util.AsyncCursor.BatchedResult;
import org.gridgain.internal.security.context.GridGainSecurity;
import org.gridgain.internal.security.context.SecurityContext;
import org.junit.jupiter.api.Test;
public class ItCursor extends BaseSqlIntegrationTest {
@Override
protected int initialNodes() {
return 1;
}
@Test
public void testCursor() {
int rowsCount = 2000;
sql("create zone test_zone with partitions=1, replicas=1,
storage_profiles='" + DEFAULT_STORAGE_PROFILE + "'");
sql("create table T (ID INT PRIMARY KEY, VAL INT) with
primary_zone='TEST_ZONE'");
sql(format("insert into T select X, X from table(system_range(1, {}))",
rowsCount));
String selectAll = "select * from T";
AsyncSqlCursor cursor1 = openSqlCursor(selectAll);
await(cursor1.onFirstPageReady());
BatchedResult f = await(cursor1.requestNextAsync(1000));
assertEquals(1000, f.items().size()); // f.items().size() is zero
}
private AsyncSqlCursor openSqlCursor(String sql) {
IgniteImpl node = CLUSTER.node(0);
SqlQueryProcessor qryProc = (SqlQueryProcessor) node.queryEngine();
SqlProperties props = SqlPropertiesHelper.emptyProperties();
SecurityContext securityCtx = GridGainSecurity.systemContext();
return Objects.requireNonNull(await(qryProc.queryAsync(props, new
HybridTimestampTracker(), null, sql, securityCtx)));
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22388) TableManagerTest revision
[
https://issues.apache.org/jira/browse/IGNITE-22388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22388:
-
Description:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTest#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above: the problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:java}
private TableManager createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:java}
@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
was:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
[jira] [Resolved] (IGNITE-22330) ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-22330.
--
Resolution: Duplicate
> ItDisasterRecoveryReconfigurationTest#testManualRebalanceIfMajorityIsLost is
> flaky
> --
>
> Key: IGNITE-22330
> URL: https://issues.apache.org/jira/browse/IGNITE-22330
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-05-25-01-56-21-327.png
>
>
> This test fails at least on main {{4c6662}} with strange (series of failures)
> rate: !image-2024-05-25-01-56-21-327.png!
> The common issue is {{{}TimeoutException{}}}:
>
> {code:java}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.awaitPrimaryReplica(ItDisasterRecoveryReconfigurationTest.java:306)
> at
> org.apache.ignite.internal.disaster.ItDisasterRecoveryReconfigurationTest.testManualRebalanceIfMajorityIsLost(ItDisasterRecoveryReconfigurationTest.java:209)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
> at
> java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
> at
> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> Caused by: java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:74)
> ... 32 more
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:74)
> at
>
[jira] [Commented] (IGNITE-22380) Add Windows start script
[
https://issues.apache.org/jira/browse/IGNITE-22380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850994#comment-17850994
]
Mikhail Pochatkin commented on IGNITE-22380:
LGTM, Thanks!
Merged to main 9c94aaab8cb67e73d43cd25aa8ef6243d6f7d560
> Add Windows start script
>
>
> Key: IGNITE-22380
> URL: https://issues.apache.org/jira/browse/IGNITE-22380
> Project: Ignite
> Issue Type: Improvement
> Components: build, cli
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the CLI distribution we have {{ignite3.bat}}, we need to add simple
> startup script for the DB distribution as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22387) Fix restart-partitions CLI unit tests
[ https://issues.apache.org/jira/browse/IGNITE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-22387: --- Epic Link: IGNITE-21140 > Fix restart-partitions CLI unit tests > - > > Key: IGNITE-22387 > URL: https://issues.apache.org/jira/browse/IGNITE-22387 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Tests use hardcoded names of options, so failed after the change of > CLUSTER_URL_OPTION. Tests should use constants values instead of hardcode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22387) Fix restart-partitions CLI unit tests
[ https://issues.apache.org/jira/browse/IGNITE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-22387: --- Labels: ignite-3 (was: ) > Fix restart-partitions CLI unit tests > - > > Key: IGNITE-22387 > URL: https://issues.apache.org/jira/browse/IGNITE-22387 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Tests use hardcoded names of options, so failed after the change of > CLUSTER_URL_OPTION. Tests should use constants values instead of hardcode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22387) Fix restart-partitions CLI unit tests
[ https://issues.apache.org/jira/browse/IGNITE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-22387: --- Description: Tests use hardcoded names of options, so failed after the change of CLUSTER_URL_OPTION. Tests should use constants values instead of hardcode. > Fix restart-partitions CLI unit tests > - > > Key: IGNITE-22387 > URL: https://issues.apache.org/jira/browse/IGNITE-22387 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Tests use hardcoded names of options, so failed after the change of > CLUSTER_URL_OPTION. Tests should use constants values instead of hardcode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22389) Get rid of CatalogUtils#collectIndexes
[ https://issues.apache.org/jira/browse/IGNITE-22389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-22389: - Fix Version/s: 3.0.0-beta2 > Get rid of CatalogUtils#collectIndexes > -- > > Key: IGNITE-22389 > URL: https://issues.apache.org/jira/browse/IGNITE-22389 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Get rid of > *org.apache.ignite.internal.catalog.commands.CatalogUtils#collectIndexes*, > which is only tested and not used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22389) Get rid of CatalogUtils#collectIndexes
Kirill Tkalenko created IGNITE-22389: Summary: Get rid of CatalogUtils#collectIndexes Key: IGNITE-22389 URL: https://issues.apache.org/jira/browse/IGNITE-22389 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Get rid of *org.apache.ignite.internal.catalog.commands.CatalogUtils#collectIndexes*, which is only tested and not used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22388) TableManagerTest revision
[
https://issues.apache.org/jira/browse/IGNITE-22388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-22388:
-
Description:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{{}TableManagerTable#tableManagerStopTest1-4{}}}. The names doesn't tell how
1st and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:java}
private TableViewInternal mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
// ...
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above: the problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:java}
private TableManager createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:java}
@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
was:
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{TableManagerTable#tableManagerStopTest1-4}}. The names doesn't tell how 1st
and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:title=|language=java|collapse=false}private TableViewInternal
mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic
[jira] [Assigned] (IGNITE-22277) Remove Zone annotation from Catalog API
[ https://issues.apache.org/jira/browse/IGNITE-22277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-22277: -- Assignee: Mikhail Pochatkin > Remove Zone annotation from Catalog API > --- > > Key: IGNITE-22277 > URL: https://issues.apache.org/jira/browse/IGNITE-22277 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Zone annotation does not make much sense - it goes on an empty class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22273) Use PUBLIC as default schema in catalog API
[ https://issues.apache.org/jira/browse/IGNITE-22273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-22273: -- Assignee: Mikhail Pochatkin > Use PUBLIC as default schema in catalog API > --- > > Key: IGNITE-22273 > URL: https://issues.apache.org/jira/browse/IGNITE-22273 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22388) TableManagerTest revision
Mikhail Efremov created IGNITE-22388:
Summary: TableManagerTest revision
Key: IGNITE-22388
URL: https://issues.apache.org/jira/browse/IGNITE-22388
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
*Description*
During IGNITE-22315 we found that tests
{{TableManagerTable#tableManagerStopTest*}} are failed and after investigations
there was clear that several static mocks aren't in use in tests that leads to
actually unworked tests. The special case was fixed in IGNITE-22355, but there
are more issued places, especially described below. The main goal of the ticket
is to revise the test class and rewrite it in accordings to its purpose without
any excessive, unused code lines.
*Motivation*
There will be provided 3 examples with problematic code the was found in
{{TableManagerTable#tableManagerStopTest*}} but not limited.
The first code smell is the name of the tests:
{{TableManagerTable#tableManagerStopTest1-4}}. The names doesn't tell how 1st
and 4th are different.
The second is another (except that in IGNITE-22355) static mock
{{schemaServiceMock}} in try-with-resources block that shouldn't work outside
the block:
{code:title=|language=java|collapse=false}private TableViewInternal
mockManagersAndCreateTableWithDelay(
String tableName,
CompletableFuture tblManagerFut,
@Nullable Phaser phaser
) throws Exception {
String consistentId = "node0";
when(ts.getByConsistentId(any())).thenReturn(new ClusterNodeImpl(
UUID.randomUUID().toString(),
consistentId,
new NetworkAddress("localhost", 47500)
));
try (MockedStatic schemaServiceMock =
mockStatic(SchemaUtils.class)) {
schemaServiceMock.when(() -> SchemaUtils.prepareSchemaDescriptor(any()))
.thenReturn(mock(SchemaDescriptor.class));
}
try (MockedStatic affinityServiceMock =
mockStatic(AffinityUtils.class)) {
ArrayList> assignment = new ArrayList<>(PARTITIONS);
for (int part = 0; part < PARTITIONS; part++) {
assignment.add(new ArrayList<>(Collections.singleton(node)));
}
affinityServiceMock.when(() ->
AffinityUtils.calculateAssignments(any(), anyInt(), anyInt()))
.thenReturn(assignment);
}
//...
{code}
In the test class there are only two such mocks and {{affinityServiceMock}} is
removed in IGNITE-22355, but {{schemaServiceMock}} still requires reworking.
The third issue in the code above is {{String consistentId = "node0"}} for mock
{{when(ts.getByConsistentId(any()))}}. The problem is that {{ts}} isn't really
uses: {{ts}} is topology service field in the test class, but for
{{TableManager}} creation topology service arrives from a mocked cluster
service:
{code:title=|language=java|collapse=false}private TableManager
createTableManager(/*...*/) {
TableManager tableManager = new TableManager(
// ...
clusterService.topologyService(),
//...
{code}
{{topologyService}} is mocked in {{before}} with another mock:
{code:title=|language=java|collapse=false}@BeforeEach
void before() throws NodeStoppingException {
// ...
TopologyService topologyService = mock(TopologyService.class);
when(clusterService.topologyService()).thenReturn(topologyService);
// ...
{code}
That means, that {{ts}} field isn't in use and the code above is just for
nothing.
There only 3 arguments, but they shows drastical problems with the test class
and the ticket calls for the class reworking.
*Definition of done*
# Tests' names should have meaningful names that differs one from another.
# Tests shouldn't contain unused and meaningless code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22107) Properly encapsulate partition meta
[
https://issues.apache.org/jira/browse/IGNITE-22107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-22107:
---
Assignee: Stanislav Markin
> Properly encapsulate partition meta
> ---
>
> Key: IGNITE-22107
> URL: https://issues.apache.org/jira/browse/IGNITE-22107
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Stanislav Markin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{PartitionMeta}} and {{PartitionMetaIo}} leak specific implementation
> details, specifically - all fields except for {{{}pageCount{}}}. This breaks
> encapsulation and makes {{page-memory}} module code non-reusable.
> I propose splitting meta into 2 parts - abstract meta, that would only hold
> page count, and specific meta that will be located in a different module,
> close to the implementation.
> In this case, we would have to pass meta IO as parameters into methods like
> {{{}PartitionMetaManager#readOrCreateMeta{}}}, and create a getter for IO in
> {{AbstractPartitionMeta}} class itself, but that's a necessary sacrifice.
> Some other places will be affected as well, mostly tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22152) Support partition filter in SQL
[ https://issues.apache.org/jira/browse/IGNITE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-22152: -- Assignee: Mikhail Pochatkin > Support partition filter in SQL > --- > > Key: IGNITE-22152 > URL: https://issues.apache.org/jira/browse/IGNITE-22152 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > After IGNITE-22065 we need to introduce filter by partition in SELECT operator -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22152) Support partition filter in SQL
[ https://issues.apache.org/jira/browse/IGNITE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-22152: --- Epic Link: (was: IGNITE-22044) > Support partition filter in SQL > --- > > Key: IGNITE-22152 > URL: https://issues.apache.org/jira/browse/IGNITE-22152 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > After IGNITE-22065 we need to introduce filter by partition in SELECT operator -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22387) Fix restart-partitions CLI unit tests
Philipp Shergalis created IGNITE-22387: -- Summary: Fix restart-partitions CLI unit tests Key: IGNITE-22387 URL: https://issues.apache.org/jira/browse/IGNITE-22387 Project: Ignite Issue Type: Improvement Components: cli Reporter: Philipp Shergalis Assignee: Philipp Shergalis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-20688:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Attachments: image001.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
> at
> com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117)
> at
>
[jira] [Assigned] (IGNITE-22193) Move IgniteJdbcDriver to non internal package
[ https://issues.apache.org/jira/browse/IGNITE-22193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-22193: --- Assignee: Iurii Gerzhedovich > Move IgniteJdbcDriver to non internal package > - > > Key: IGNITE-22193 > URL: https://issues.apache.org/jira/browse/IGNITE-22193 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Right now we have org.apache.ignite.internal.jdbc.IgniteJdbcDriver which is > placed in `internal' package. Most database utilities working with JDBC > drivers show the name to users, e.g. DBeaver. > This approach is not user-friendly. Let's move the class to > `org.apache.ignite.jdbc` package -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[
https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850944#comment-17850944
]
Aleksey Plekhanov commented on IGNITE-22381:
[~serge.korotkov], [~nshakarov], [~anovikov] can you please have a look.
Changes have been made:
* Moved {{gatling-ext}} module under {{java-11+}} profile (some dependencies
of this module compiled with java-11 and can't be recognized by java-8).
* For {{java-11+}} profile target compiler version is set to 11 (the same we
have for the parent {{ignite}} project, even if we try to compile with 1.8
target, compiled classes still can't be used by java-8, but {{target=1.8}} or
{{release=1.8}} brokes usage of {{{}add-opens{}}}).
* Gatling maven plugin execution is disabled when {{-DskipTest}} or
{{-Dmaven.test.skip=true}} parameters are passed to maven (currently, this
plugin always executed on test phase, even if we disable tests explicitely).
* Options {{--add-opens}} also added to {{java-11+}} (They are not mandatory
for java-11, but they remove warnings about reflection usage).
Tested compilation locally on java8, java11, java17 (unfortunately java21
compilation still not working due to some {{spark-ext}} problems).
Tested with {{-DskipTest}} and {{-Dmaven.test.skip=true}} JVM options.
Started tests on both team-city servers.
> Extensions: Broken compilation by java8, java11
>
>
> Key: IGNITE-22381
> URL: https://issues.apache.org/jira/browse/IGNITE-22381
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Compilation on java8 is broken by IGNITE-21679
> Compilation on java11 is broken by IGNITE-22077
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16073) Test for keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov resolved IGNITE-16073. Resolution: Invalid > Test for keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Major > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[ https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22381: --- Description: Compilation on java8 is broken by IGNITE-21679 Compilation on java11 is broken by IGNITE-22077 was: Compilation by java8 broken by IGNITE-21679 Compilation by java11 broken by IGNITE-22077 > Extensions: Broken compilation by java8, java11 > > > Key: IGNITE-22381 > URL: https://issues.apache.org/jira/browse/IGNITE-22381 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Compilation on java8 is broken by IGNITE-21679 > Compilation on java11 is broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22386) Many usages of wrong revision serialization in metastorage commands
[
https://issues.apache.org/jira/browse/IGNITE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-22386:
--
Assignee: Ivan Bessonov
> Many usages of wrong revision serialization in metastorage commands
> ---
>
> Key: IGNITE-22386
> URL: https://issues.apache.org/jira/browse/IGNITE-22386
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> byte[] revisionBytes = ByteUtils.longToBytes(revision);
> Iif iif = iif(
> notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
> {code}
> Code above has a bug - "longToBytes" is not a suitable serialization format
> for preserving natural comparison order used in "lt". We must fix it, because
> it leads to occasional false-positive and false-negative condition evaluation
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22386) Many usages of wrong revision serialization in metastorage commands
[
https://issues.apache.org/jira/browse/IGNITE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-22386:
---
Description:
{code:java}
byte[] revisionBytes = ByteUtils.longToBytes(revision);
Iif iif = iif(
notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
{code}
Code above has a bug - "longToBytes" is not a suitable serialization format for
preserving natural comparison order used in "lt". We must fix it, because it
leads to occasional false-positive and false-negative condition evaluation
It also leads to flaky tests, obviously
was:
{code:java}
byte[] revisionBytes = ByteUtils.longToBytes(revision);
Iif iif = iif(
notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
{code}
Code above has a bug - "longToBytes" is not a suitable serialization format for
preserving natural comparison order used in "lt". We must fix it, because it
leads to occasional false-positive and false-negative condition evaluation
> Many usages of wrong revision serialization in metastorage commands
> ---
>
> Key: IGNITE-22386
> URL: https://issues.apache.org/jira/browse/IGNITE-22386
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> byte[] revisionBytes = ByteUtils.longToBytes(revision);
> Iif iif = iif(
> notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
> {code}
> Code above has a bug - "longToBytes" is not a suitable serialization format
> for preserving natural comparison order used in "lt". We must fix it, because
> it leads to occasional false-positive and false-negative condition evaluation
> It also leads to flaky tests, obviously
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22386) Many usages of wrong revision serialization in metastorage commands
Ivan Bessonov created IGNITE-22386:
--
Summary: Many usages of wrong revision serialization in
metastorage commands
Key: IGNITE-22386
URL: https://issues.apache.org/jira/browse/IGNITE-22386
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
{code:java}
byte[] revisionBytes = ByteUtils.longToBytes(revision);
Iif iif = iif(
notExists(partChangeTriggerKey).or(value(partChangeTriggerKey).lt(revisionBytes)),
{code}
Code above has a bug - "longToBytes" is not a suitable serialization format for
preserving natural comparison order used in "lt". We must fix it, because it
leads to occasional false-positive and false-negative condition evaluation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
