[jira] [Updated] (IGNITE-24274) Sql. Inbox does not handle closing properly
[ https://issues.apache.org/jira/browse/IGNITE-24274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-24274: -- Summary: Sql. Inbox does not handle closing properly (was: Sql. Inbox push throws AssertionError when called after Inbox close) > Sql. Inbox does not handle closing properly > --- > > Key: IGNITE-24274 > URL: https://issues.apache.org/jira/browse/IGNITE-24274 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Inbox operator does not handle closing properly, because it is possible to > invoke Inbox close, then to get a queued call to Inbox doPush and get an > AssertionError. > Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that > cancels a DML query during execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24274) Sql. Inbox does not handle closing properly
[ https://issues.apache.org/jira/browse/IGNITE-24274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-24274: -- Description: Inbox operator does not handle closing properly, because it is possible to invoke Inbox close, then to get a queued call to Inbox doPush that eventually runs some operator's logic. was: Inbox operator does not handle closing properly, because it is possible to invoke Inbox close, then to get a queued call to Inbox doPush and get an AssertionError. Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that cancels a DML query during execution. > Sql. Inbox does not handle closing properly > --- > > Key: IGNITE-24274 > URL: https://issues.apache.org/jira/browse/IGNITE-24274 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Inbox operator does not handle closing properly, because it is possible to > invoke Inbox close, then to get a queued call to Inbox doPush that eventually > runs some operator's logic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24215) Improve internal Catalog API
[ https://issues.apache.org/jira/browse/IGNITE-24215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-24215: - Assignee: Andrey Mashenkov > Improve internal Catalog API > > > Key: IGNITE-24215 > URL: https://issues.apache.org/jira/browse/IGNITE-24215 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > > On one hand, `Catalog` class is an internal container for descriptors and > wasn't designed to be used directly outside the module. > On the other hand `CatalogService` interface has a bunch of similar methods > for accessing catalog internals. > Let's disclose `Catalog` class: describe it in README.md of `ignite-catalog` > module, write javadocs and maybe add some shortcut method (e.g. > `table(schemaName, tableName)`) > Let's remove all the methods, which returns `Catalog` class internals, from > `CatalogService`. > So, `CatalogService` should have few methods that answer the question: > * which catalog version is actual at point-in-time > * which catalog version is earliest/latest > * when catalog is initialized/catalog version is ready by returning a future. > * gets `Catalog` snapshot for version/point-in-time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24267) Reduce heap footprint for Lock manager
[ https://issues.apache.org/jira/browse/IGNITE-24267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-24267: -- Assignee: Vladislav Pyatkov > Reduce heap footprint for Lock manager > -- > > Key: IGNITE-24267 > URL: https://issues.apache.org/jira/browse/IGNITE-24267 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24267) Reduce heap footprint for Lock manager
Vladislav Pyatkov created IGNITE-24267: -- Summary: Reduce heap footprint for Lock manager Key: IGNITE-24267 URL: https://issues.apache.org/jira/browse/IGNITE-24267 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24267) Reduce heap footprint for Lock manager
[
https://issues.apache.org/jira/browse/IGNITE-24267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-24267:
---
Description:
h3. Motivation
We preallocate much memory on the lock manager initialization.
{code}
locks = new ConcurrentHashMap<>(lockMapSize);
LockState[] tmp = new LockState[rawSlotsMaxSize];
for (int i = 0; i < tmp.length; i++) {
LockState lockState = new LockState();
if (i < lockMapSize) {
empty.add(lockState);
}
tmp[i] = lockState;
}
slots = tmp; // Atomic init.
{code}
> Reduce heap footprint for Lock manager
> --
>
> Key: IGNITE-24267
> URL: https://issues.apache.org/jira/browse/IGNITE-24267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> h3. Motivation
> We preallocate much memory on the lock manager initialization.
> {code}
> locks = new ConcurrentHashMap<>(lockMapSize);
> LockState[] tmp = new LockState[rawSlotsMaxSize];
> for (int i = 0; i < tmp.length; i++) {
> LockState lockState = new LockState();
> if (i < lockMapSize) {
> empty.add(lockState);
> }
> tmp[i] = lockState;
> }
> slots = tmp; // Atomic init.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24268) Minor refactoring in PartitionReplicaLifecycleManager
Aleksandr Polovtsev created IGNITE-24268: Summary: Minor refactoring in PartitionReplicaLifecycleManager Key: IGNITE-24268 URL: https://issues.apache.org/jira/browse/IGNITE-24268 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtsev Assignee: Aleksandr Polovtsev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24272) Search for inappropriate java system properties
Mikhail Efremov created IGNITE-24272: Summary: Search for inappropriate java system properties Key: IGNITE-24272 URL: https://issues.apache.org/jira/browse/IGNITE-24272 Project: Ignite Issue Type: Task Reporter: Mikhail Efremov Assignee: Mikhail Efremov *Description* After a discussion there is an issue with system properties in AI3 code base that may be used as configuration tool instead of configuration files usage. The situation requires an actions and first of all to refine system properties: are they really an internal mechanisms for test-only purposes or some are mistaken and should be redone as configuration's entries. *Motivation* We should use strict policy for user accessible mechanisms as jvm properties. *Definition of Done* 1. All system properties are inspected and developers who added them are communicated. 2. All system properties that are intended for configuration should be mentioned in the new ticket about changing mistaken properties to configuration values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24187) Fix code style issues in SystemDistributedConfigurationPropertyHolder
[ https://issues.apache.org/jira/browse/IGNITE-24187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24187: - Fix Version/s: 3.0 > Fix code style issues in SystemDistributedConfigurationPropertyHolder > - > > Key: IGNITE-24187 > URL: https://issues.apache.org/jira/browse/IGNITE-24187 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Several issues must be fixed: > 1. ObjLongConsumer instead of BiConsumer > 2. AtomicReference with simple set/get must be replaced by volatile field -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24029) Sql schema. Extend Table API with supporting qualified names.
[
https://issues.apache.org/jira/browse/IGNITE-24029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914925#comment-17914925
]
Andrey Mashenkov commented on IGNITE-24029:
---
[~ptupitsyn], [~isapego],
I've prepared a PR for supporting Sql-schema for tables and found a platform
clients do not follow SQL convention for identifiers (table names) and some
tests were failed.
I've fixed these tests and add TODOs, which should be resolved in follow-up
tickets [1], [2].
Would you please do review for the changes in platform code?
For your convenience, the PR contains 2 separate commits that affect only .NET
and C++ code.
https://issues.apache.org/jira/browse/IGNITE-24258 - .NET
https://issues.apache.org/jira/browse/IGNITE-24261 - C++
> Sql schema. Extend Table API with supporting qualified names.
> -
>
> Key: IGNITE-24029
> URL: https://issues.apache.org/jira/browse/IGNITE-24029
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is necessary to introduce new methods in IgniteTables that use
> {{QualifiedName}} instead of simple String.
> And change the old ones to use the new ones using the helper method
> {{{}QualifiedName.parseof(String){}}}.
> {code:java}
> interface IgniteTables {
> /** Gets a list of all tables */
> List tables();
> /** Gets a list of tables that belong to requested schema. */
> List tables(String schemaName); // optional
> /** Gets a table with specified name. */
> @Nullable Table table(QualifiedName tableName);
> @Nullable Table table(String tableName) {
> return table(QualifiedName.parseof(tableName));
> }
> /* ... + async methods ... */
> }
> public interface Table {
> /** Returns table's qualified name. */
> QualifiedName tableName();
> }
> {code}
> Add integration tests, which checks cache names are correctly resolved.
> Add table::name that returns a QualifiedName.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24271) Do not pass NodeStoppingException to FailureHandler in WatchProcessor
[ https://issues.apache.org/jira/browse/IGNITE-24271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24271: --- Description: Otherwise, stopping a node might make it fail > Do not pass NodeStoppingException to FailureHandler in WatchProcessor > - > > Key: IGNITE-24271 > URL: https://issues.apache.org/jira/browse/IGNITE-24271 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Otherwise, stopping a node might make it fail -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23365) Fix huge log message with assignments
[
https://issues.apache.org/jira/browse/IGNITE-23365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-23365:
Assignee: Vyacheslav Koptilin (was: Alexander Lapin)
> Fix huge log message with assignments
> -
>
> Key: IGNITE-23365
> URL: https://issues.apache.org/jira/browse/IGNITE-23365
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Attachments: assignments.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When starting a node, we can write a message like this:
> {code:java}
> [2024-10-04T13:08:50,921][INFO
> ][%node_3344%JRaft-ReadOnlyService-Disruptor_stripe_0-0][AssignmentsTracker]
> Assignment cache initialized for placement driver
> [groupAssignments={12_part_12=TokenizedAssignmentsImpl [nodes=UnmodifiableSet
> [Assignment [consistentId=node_3345, isPeer=true]], token=1334],
> 20_part_20=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3346, isPeer=true]], token=1969],
> 22_part_22=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3344, isPeer=true]], token=997],
> 12_part_13=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3345, isPeer=true]], token=1323],
> 20_part_21=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3344, isPeer=true]], token=1004],
> 22_part_23=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3346, isPeer=true]], token=1978],
> 25_part_24=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3346, isPeer=true]], token=2019],
> 12_part_14=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3345, isPeer=true]], token=1327],
> 20_part_22=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3344, isPeer=true]], token=1012],
> 22_part_20=TokenizedAssignmentsImpl [nodes=UnmodifiableSet [Assignment
> [consistentId=node_3346, isPeer=true]], token=1974],...{code}
> Full message is in the attachment. We should make it shorter.
> h3. UPD 1
> Following log format should be used:
> {code:java}
> node_3344: peers = {12_part_12, 12_part_14, 20_part_12}, learners =
> {23_part_12, 12_part_14, 20_part_12}
> node_3345: peers = {12_part_12, 12_part_14, 20_part_12}, learners =
> {23_part_12, 12_part_14, 20_part_12}
> node_3346: peers = {12_part_12, 12_part_14, 20_part_12}, learners =
> {23_part_12, 12_part_14, 20_part_12} {code}
> Both in case of single table/zone and multiple entities like we have in
> PlacementDriver.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24273) Fix flaky ItNodeTest#testInstallSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-24273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-24273:
-
Summary: Fix flaky ItNodeTest#testInstallSnapshot (was: Investigate flaky
ItNodeTest#testInstallSnapshot)
> Fix flaky ItNodeTest#testInstallSnapshot
>
>
> Key: IGNITE-24273
> URL: https://issues.apache.org/jira/browse/IGNITE-24273
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> We need to deal with flaky
> *org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
> Link to
> [TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
> 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.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at
> app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
> at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24273) Investigate flaky ItNodeTest#testInstallSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-24273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-24273:
-
Issue Type: Bug (was: Task)
> Investigate flaky ItNodeTest#testInstallSnapshot
>
>
> Key: IGNITE-24273
> URL: https://issues.apache.org/jira/browse/IGNITE-24273
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> We need to deal with flaky
> *org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
> Link to
> [TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
> 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.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at
> app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
> at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24276) Thin 3.0: TABLE_GET does not return actual table name
Pavel Tupitsyn created IGNITE-24276: --- Summary: Thin 3.0: TABLE_GET does not return actual table name Key: IGNITE-24276 URL: https://issues.apache.org/jira/browse/IGNITE-24276 Project: Ignite Issue Type: Bug Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0 TABLE_GET client op should return the original table name, including schema, so that the user understands which table was resolved (according to name parsing rules, default schema, etc). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24276) Thin 3.0: TABLE_GET does not return actual table name
[ https://issues.apache.org/jira/browse/IGNITE-24276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-24276: Labels: ignite-3 important (was: ignite-3) > Thin 3.0: TABLE_GET does not return actual table name > - > > Key: IGNITE-24276 > URL: https://issues.apache.org/jira/browse/IGNITE-24276 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3, important > Fix For: 3.0 > > > TABLE_GET client op should return the original table name, including schema, > so that the user understands which table was resolved (according to name > parsing rules, default schema, etc). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24254) Sql schema. Fix Thin client protocol to use schema names
[ https://issues.apache.org/jira/browse/IGNITE-24254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914977#comment-17914977 ] Pavel Tupitsyn commented on IGNITE-24254: - Discussed with [~amashenkov], decided to revert: * For 3.0, we don't support schemas * For 3.1 we'll add schemas support, and we want to maintain two-way client compat (3.0 client can work with 3.1 server and vice versa) Therefore, we'll keep current TABLE_GET and TABLES_GET operations as is (name only, no schema), and introduce new ones that work with parsed names. > Sql schema. Fix Thin client protocol to use schema names > > > Key: IGNITE-24254 > URL: https://issues.apache.org/jira/browse/IGNITE-24254 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Andrey Mashenkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Table can be unambiguously identified either by id or by pair of schema name > and table name. > So, Thin Client protocol should be aware of schema name a table belongs to. > ClientTables, *ClientTableGetRequest* and *ClientTablesGetRequest* should > either read/write table canonical name (see `QualifiedName.toCanonicalName`) > or transfer schema name with the table name. > I'd prefer second approach with 2 separate Strings, to avoid excessive > parsing and quoting names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-24254) Sql schema. Fix Thin client protocol to use schema names
[ https://issues.apache.org/jira/browse/IGNITE-24254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reopened IGNITE-24254: - > Sql schema. Fix Thin client protocol to use schema names > > > Key: IGNITE-24254 > URL: https://issues.apache.org/jira/browse/IGNITE-24254 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Andrey Mashenkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Table can be unambiguously identified either by id or by pair of schema name > and table name. > So, Thin Client protocol should be aware of schema name a table belongs to. > ClientTables, *ClientTableGetRequest* and *ClientTablesGetRequest* should > either read/write table canonical name (see `QualifiedName.toCanonicalName`) > or transfer schema name with the table name. > I'd prefer second approach with 2 separate Strings, to avoid excessive > parsing and quoting names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-24254) Sql schema. Fix Thin client protocol to use schema names
[ https://issues.apache.org/jira/browse/IGNITE-24254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-24254. - Resolution: Won't Fix > Sql schema. Fix Thin client protocol to use schema names > > > Key: IGNITE-24254 > URL: https://issues.apache.org/jira/browse/IGNITE-24254 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Andrey Mashenkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Table can be unambiguously identified either by id or by pair of schema name > and table name. > So, Thin Client protocol should be aware of schema name a table belongs to. > ClientTables, *ClientTableGetRequest* and *ClientTablesGetRequest* should > either read/write table canonical name (see `QualifiedName.toCanonicalName`) > or transfer schema name with the table name. > I'd prefer second approach with 2 separate Strings, to avoid excessive > parsing and quoting names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24254) Sql schema. Fix Thin client protocol to use schema names
[ https://issues.apache.org/jira/browse/IGNITE-24254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914978#comment-17914978 ] Pavel Tupitsyn commented on IGNITE-24254: - Reverted: https://github.com/apache/ignite-3/commit/46b7a33b9765dd0fc1c1c2af4e5dad402ecd3c6e > Sql schema. Fix Thin client protocol to use schema names > > > Key: IGNITE-24254 > URL: https://issues.apache.org/jira/browse/IGNITE-24254 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Andrey Mashenkov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Table can be unambiguously identified either by id or by pair of schema name > and table name. > So, Thin Client protocol should be aware of schema name a table belongs to. > ClientTables, *ClientTableGetRequest* and *ClientTablesGetRequest* should > either read/write table canonical name (see `QualifiedName.toCanonicalName`) > or transfer schema name with the table name. > I'd prefer second approach with 2 separate Strings, to avoid excessive > parsing and quoting names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24231) Implement hasUserInputAfterLastReconfiguration method
[
https://issues.apache.org/jira/browse/IGNITE-24231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-24231:
-
Description:
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-23882 we have described the way
how we will track if user input has happened after raft reconfiguration. For
the purposes of the provided algorithm, we have to implement flag in
{{PartitionDataStorage}} and {{PartitionListener}}. See details in the ticket.
This method must be effectively represented as flag, and must be updated
according to algo in https://issues.apache.org/jira/browse/IGNITE-23882. Actual
update of this method must be done when the whole algo will be implemented in
https://issues.apache.org/jira/browse/IGNITE-23882, so this ticket is
prerequisite.
h3. Implementation notes
{{hasUserInputAfterLastReconfiguration}} must be update atomically in
storageUpdateHandler.handleUpdate
h3. Definition of done
* New method {{hasUserInputAfterLastReconfiguration}} must be implemented in
{{PartitionDataStorage}} and {{PartitionListener}}
> Implement hasUserInputAfterLastReconfiguration method
> --
>
> Key: IGNITE-24231
> URL: https://issues.apache.org/jira/browse/IGNITE-24231
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-23882 we have described the
> way how we will track if user input has happened after raft reconfiguration.
> For the purposes of the provided algorithm, we have to implement flag in
> {{PartitionDataStorage}} and {{PartitionListener}}. See details in the
> ticket.
> This method must be effectively represented as flag, and must be updated
> according to algo in https://issues.apache.org/jira/browse/IGNITE-23882.
> Actual update of this method must be done when the whole algo will be
> implemented in https://issues.apache.org/jira/browse/IGNITE-23882, so this
> ticket is prerequisite.
> h3. Implementation notes
> {{hasUserInputAfterLastReconfiguration}} must be update atomically in
> storageUpdateHandler.handleUpdate
> h3. Definition of done
> * New method {{hasUserInputAfterLastReconfiguration}} must be implemented in
> {{PartitionDataStorage}} and {{PartitionListener}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24055) Distinguished SQL operation to update observation timestamp
[
https://issues.apache.org/jira/browse/IGNITE-24055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24055:
--
Fix Version/s: 3.0
(was: 3.1)
> Distinguished SQL operation to update observation timestamp
> ---
>
> Key: IGNITE-24055
> URL: https://issues.apache.org/jira/browse/IGNITE-24055
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Motivation
> Currently, we need to update observation timestamp in
> {{ClientInboundMessageHandler}} for any SQL because the script can contain an
> DDL operation (for example, "CREATE TABLE"). But it is not necessary for any
> DML.
> h3. Definition of done
> Update the observation timestamp only for that operation where it is required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24271) Do not pass NodeStoppingException to FailureHandler in WatchProcessor
Roman Puchkovskiy created IGNITE-24271: -- Summary: Do not pass NodeStoppingException to FailureHandler in WatchProcessor Key: IGNITE-24271 URL: https://issues.apache.org/jira/browse/IGNITE-24271 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24275) Sql. Rework or replace HybridTimestampTracker.clientTracker
Pavel Pereslegin created IGNITE-24275:
-
Summary: Sql. Rework or replace
HybridTimestampTracker.clientTracker
Key: IGNITE-24275
URL: https://issues.apache.org/jira/browse/IGNITE-24275
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
In summary, the requirements for a {{HybridTimestampTracker}} (*observable time
tracker*) are as follows:
* Observed time can be updated multiple times
* Observed time can be updated from different threads
* The updated value should be visible from different threads
* When updating the time, the tracker must provide a guarantee that the updated
value is monotonically increasing
>From that perspective current implementation of
>{{HybridTimestampTracker.clientTracker}} is broken.
* The method {{get()}} returns only initial value
* Consumer usually stores value to non-volatile field
* There is no check that the new value is greater than the previous one
We need to rework {{clientTracker}} to meet requirement or replace it where
with {{atomicTracker}}.
p.s. check TODO in codebase
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24273) Fix flaky ItNodeTest#testInstallSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-24273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-24273:
-
Description:
We need to deal with flaky
*org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
Link to
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
The problem is that between snapshot creations we execute 10 more tasks that
should increase the last applied index, but due to the race this does not have
time to happen at the moment of the repeated request for snapshot creation, the
test needs to be fixed.
A little more detail on where the race occurs.
Between snapshot creations,
*org.apache.ignite.raft.jraft.core.ItNodeTest#sendTestTaskAndWait* is called,
which complete latch of all tasks in the state machine, but since this happens
in another thread, the test thread starts executing earlier and requests the
creation of a snapshot before the last applied index in
*org.apache.ignite.raft.jraft.core.FSMCallerImpl* is updated, so when
requesting the creation of a snapshot, we do not have time to understand that
something has changed in the state machine and is needed and we skip the
creation of a snapshot.
{noformat}
org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
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.AssertEquals.failNotEqual(AssertEquals.java:197)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
{noformat}
was:
We need to deal with flaky
*org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
Link to
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
{noformat}
org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
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.AssertEquals.failNotEqual(AssertEquals.java:197)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
{noformat}
> Fix flaky ItNodeTest#testInstallSnapshot
>
>
> Key: IGNITE-24273
> URL: https://issues.apache.org/jira/browse/IGNITE-24273
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> We need to deal with flaky
> *org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
> Link to
> [TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
> The problem is that between snapshot creations we execute 10 more tasks that
> should increase the last applied index, but due to the race this does not
> have time to happen at the moment of the repeated request for snapshot
> creation, the test needs to be fixed.
> A little more detail on where the race occurs.
> Between snapshot creations,
> *org.apache.ignite.raft.jraft.core.ItNodeTest#sendTestTaskAndWait* is called,
> which complete latch of all tasks in the state machine, but since this
> happens in another t
[jira] [Updated] (IGNITE-24273) Fix flaky ItNodeTest#testInstallSnapshot
[
https://issues.apache.org/jira/browse/IGNITE-24273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-24273:
-
Description:
We need to deal with flaky
*org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
Link to
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
{noformat}
org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
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.AssertEquals.failNotEqual(AssertEquals.java:197)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
{noformat}
The problem is that between snapshot creations we execute 10 more tasks that
should increase the last applied index, but due to the race this does not have
time to happen at the moment of the repeated request for snapshot creation, the
test needs to be fixed.
A little more detail on where the race occurs.
Between snapshot creations,
*org.apache.ignite.raft.jraft.core.ItNodeTest#sendTestTaskAndWait* is called,
which complete latch of all tasks in the state machine, but since this happens
in another thread, the test thread starts executing earlier and requests the
creation of a snapshot before the last applied index in
*org.apache.ignite.raft.jraft.core.FSMCallerImpl* is updated, so when
requesting the creation of a snapshot, we do not have time to understand that
something has changed in the state machine and is needed and we skip the
creation of a snapshot.
was:
We need to deal with flaky
*org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
Link to
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
The problem is that between snapshot creations we execute 10 more tasks that
should increase the last applied index, but due to the race this does not have
time to happen at the moment of the repeated request for snapshot creation, the
test needs to be fixed.
A little more detail on where the race occurs.
Between snapshot creations,
*org.apache.ignite.raft.jraft.core.ItNodeTest#sendTestTaskAndWait* is called,
which complete latch of all tasks in the state machine, but since this happens
in another thread, the test thread starts executing earlier and requests the
creation of a snapshot before the last applied index in
*org.apache.ignite.raft.jraft.core.FSMCallerImpl* is updated, so when
requesting the creation of a snapshot, we do not have time to understand that
something has changed in the state machine and is needed and we skip the
creation of a snapshot.
{noformat}
org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
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.AssertEquals.failNotEqual(AssertEquals.java:197)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
{noformat}
> Fix flaky ItNodeTest#testInstallSnapshot
>
>
> Key: IGNITE-24273
> URL: https://issues.apache.org/jira/browse/IGNITE-24273
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>
[jira] [Updated] (IGNITE-24275) Sql. Rework or replace HybridTimestampTracker.clientTracker
[
https://issues.apache.org/jira/browse/IGNITE-24275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24275:
--
Description:
In summary, the requirements for a {{HybridTimestampTracker}} (*observable time
tracker*) are as follows:
* Observed time can be updated multiple times
* Observed time can be updated from different threads
* The updated value should be visible from different threads
* When updating the time, the tracker must provide a guarantee that the updated
value is monotonically increasing
>From that perspective current implementation of
>{{HybridTimestampTracker.clientTracker}} is broken.
* The method {{get()}} returns only initial value (so tracker cannot be used
multiple times, for example for SQL script processing)
* Consumer usually stores value to non-volatile field
* There is no check that the new value is greater than the previous one
We need to rework {{clientTracker}} to meet requirement or replace it where
with {{atomicTracker}}.
p.s. check TODO in codebase
was:
In summary, the requirements for a {{HybridTimestampTracker}} (*observable time
tracker*) are as follows:
* Observed time can be updated multiple times
* Observed time can be updated from different threads
* The updated value should be visible from different threads
* When updating the time, the tracker must provide a guarantee that the updated
value is monotonically increasing
>From that perspective current implementation of
>{{HybridTimestampTracker.clientTracker}} is broken.
* The method {{get()}} returns only initial value
* Consumer usually stores value to non-volatile field
* There is no check that the new value is greater than the previous one
We need to rework {{clientTracker}} to meet requirement or replace it where
with {{atomicTracker}}.
p.s. check TODO in codebase
> Sql. Rework or replace HybridTimestampTracker.clientTracker
> ---
>
> Key: IGNITE-24275
> URL: https://issues.apache.org/jira/browse/IGNITE-24275
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> In summary, the requirements for a {{HybridTimestampTracker}} (*observable
> time tracker*) are as follows:
> * Observed time can be updated multiple times
> * Observed time can be updated from different threads
> * The updated value should be visible from different threads
> * When updating the time, the tracker must provide a guarantee that the
> updated value is monotonically increasing
> From that perspective current implementation of
> {{HybridTimestampTracker.clientTracker}} is broken.
> * The method {{get()}} returns only initial value (so tracker cannot be used
> multiple times, for example for SQL script processing)
> * Consumer usually stores value to non-volatile field
> * There is no check that the new value is greater than the previous one
> We need to rework {{clientTracker}} to meet requirement or replace it where
> with {{atomicTracker}}.
> p.s. check TODO in codebase
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24262) AssertionError in ClusterTimeImpl.startSafeTimeScheduler
[ https://issues.apache.org/jira/browse/IGNITE-24262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin reassigned IGNITE-24262: Assignee: Philipp Shergalis > AssertionError in ClusterTimeImpl.startSafeTimeScheduler > > > Key: IGNITE-24262 > URL: https://issues.apache.org/jira/browse/IGNITE-24262 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Attachments: _Integration_Tests_Run_All_Other_31480.log.zip > > > AssertionError was thrown by ClusterTimeImpl.startSafeTimeScheduler() in > ItCatalogCompactionCoordinatorChoosingTest, see the attached log -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23772) Calcite. Incorrect processing of old date literals.
[
https://issues.apache.org/jira/browse/IGNITE-23772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23772:
--
Summary: Calcite. Incorrect processing of old date literals. (was:
Calcite. Incorrect processing of old dates.)
> Calcite. Incorrect processing of old date literals.
> ---
>
> Key: IGNITE-23772
> URL: https://issues.apache.org/jira/browse/IGNITE-23772
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: calcite, ignite-2, ise
>
> Consider:
> *1)* {code:java}
> assertQuery("SELECT DATE '1582-10-05' + INTERVAL 1
> DAYS").returns(Date.valueOf("1582-10-06")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1582-10-05 00:00:00' + INTERVAL 1
> DAYS").returns(Timestamp.valueOf("1582-10-06 00:00:00")).check();
> {code}
> Result:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to validate query. From line 1, column 25 to line 1, column 41: Illegal DATE
> literal '1582-10-05': not in format '-MM-dd'
> ---
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to validate query. From line 1, column 25 to line 1, column 55: Illegal
> TIMESTAMP literal '1582-10-05 00:00:00': not in format '-MM-dd HH:mm:ss'
> {code}
> *2)* {code:java}
> assertQuery("SELECT DATE '1582-10-01' + INTERVAL 1
> DAYS").returns(Date.valueOf("1582-10-02")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1582-10-01 00:00:00' + INTERVAL 1
> DAYS").returns(Timestamp.valueOf("1582-10-02 00:00:00")).check();
> {code}
> Result:
> Doesn't fail, but but the result is incorrect.
> {code:java}
> java.lang.AssertionError: Collections are not equal (position 0):
> Expected: [[1582-10-02]]
> Actual: [[1582-09-22]]
> ---
> java.lang.AssertionError: Collections are not equal (position 0):
> Expected: [[1582-10-02 00:00:00.0]]
> Actual: [[1582-09-22 00:00:00.0]]
> {code}
> *3)* OK
> {code:java}
> assertQuery("SELECT DATE '1583-10-05' + INTERVAL 1
> DAYS").returns(Date.valueOf("1583-10-06")).check();
> ---
> assertQuery("SELECT TIMESTAMP '1583-10-01 00:00:00' + INTERVAL 1
> DAYS").returns(Timestamp.valueOf("1583-10-02 00:00:00")).check();
> {code}
> The problem is in variation of date conversion in java.util.Date (used in
> _TypeUtils#fromInterna()_). There is a threshold year 1582 (october) to
> calculate in Gregorian calendar.
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1238
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1279
> When Avatica does calculation in Julian calendar.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24029) Sql schema. Extend Table API with supporting qualified names.
[
https://issues.apache.org/jira/browse/IGNITE-24029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-24029:
Fix Version/s: 3.1
(was: 3.0)
> Sql schema. Extend Table API with supporting qualified names.
> -
>
> Key: IGNITE-24029
> URL: https://issues.apache.org/jira/browse/IGNITE-24029
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is necessary to introduce new methods in IgniteTables that use
> {{QualifiedName}} instead of simple String.
> And change the old ones to use the new ones using the helper method
> {{{}QualifiedName.parseof(String){}}}.
> {code:java}
> interface IgniteTables {
> /** Gets a list of all tables */
> List tables();
> /** Gets a list of tables that belong to requested schema. */
> List tables(String schemaName); // optional
> /** Gets a table with specified name. */
> @Nullable Table table(QualifiedName tableName);
> @Nullable Table table(String tableName) {
> return table(QualifiedName.parseof(tableName));
> }
> /* ... + async methods ... */
> }
> public interface Table {
> /** Returns table's qualified name. */
> QualifiedName tableName();
> }
> {code}
> Add integration tests, which checks cache names are correctly resolved.
> Add table::name that returns a QualifiedName.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23772) Calcite. Incorrect processing of old date literals.
[
https://issues.apache.org/jira/browse/IGNITE-23772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23772:
--
Description:
Consider:
*1)* {code:java}
assertQuery("SELECT DATE '1582-10-05' + INTERVAL 1
DAYS").returns(Date.valueOf("1582-10-06")).check();
---
assertQuery("SELECT TIMESTAMP '1582-10-05 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1582-10-06 00:00:00")).check();
{code}
Result:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query. From line 1, column 25 to line 1, column 41: Illegal DATE
literal '1582-10-05': not in format '-MM-dd'
---
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query. From line 1, column 25 to line 1, column 55: Illegal TIMESTAMP
literal '1582-10-05 00:00:00': not in format '-MM-dd HH:mm:ss'
{code}
*2)* {code:java}
assertQuery("SELECT DATE '1582-10-01' + INTERVAL 1
DAYS").returns(Date.valueOf("1582-10-02")).check();
---
assertQuery("SELECT TIMESTAMP '1582-10-01 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1582-10-02 00:00:00")).check();
{code}
Result:
Doesn't fail, but but the result is incorrect.
{code:java}
java.lang.AssertionError: Collections are not equal (position 0):
Expected: [[1582-10-02]]
Actual: [[1582-09-22]]
---
java.lang.AssertionError: Collections are not equal (position 0):
Expected: [[1582-10-02 00:00:00.0]]
Actual: [[1582-09-22 00:00:00.0]]
{code}
*3)* OK
{code:java}
assertQuery("SELECT DATE '1583-10-05' + INTERVAL 1
DAYS").returns(Date.valueOf("1583-10-06")).check();
---
assertQuery("SELECT TIMESTAMP '1583-10-01 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1583-10-02 00:00:00")).check();
{code}
The problem is in variation of date conversion in java.util.Date (used in
_TypeUtils#fromInterna()_). There is a threshold year 1582 (october).
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1238
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1279
When Avatica always does trivial calculation using days, milliseconds related
to 1970-01-01.
was:
Consider:
*1)* {code:java}
assertQuery("SELECT DATE '1582-10-05' + INTERVAL 1
DAYS").returns(Date.valueOf("1582-10-06")).check();
---
assertQuery("SELECT TIMESTAMP '1582-10-05 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1582-10-06 00:00:00")).check();
{code}
Result:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query. From line 1, column 25 to line 1, column 41: Illegal DATE
literal '1582-10-05': not in format '-MM-dd'
---
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
validate query. From line 1, column 25 to line 1, column 55: Illegal TIMESTAMP
literal '1582-10-05 00:00:00': not in format '-MM-dd HH:mm:ss'
{code}
*2)* {code:java}
assertQuery("SELECT DATE '1582-10-01' + INTERVAL 1
DAYS").returns(Date.valueOf("1582-10-02")).check();
---
assertQuery("SELECT TIMESTAMP '1582-10-01 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1582-10-02 00:00:00")).check();
{code}
Result:
Doesn't fail, but but the result is incorrect.
{code:java}
java.lang.AssertionError: Collections are not equal (position 0):
Expected: [[1582-10-02]]
Actual: [[1582-09-22]]
---
java.lang.AssertionError: Collections are not equal (position 0):
Expected: [[1582-10-02 00:00:00.0]]
Actual: [[1582-09-22 00:00:00.0]]
{code}
*3)* OK
{code:java}
assertQuery("SELECT DATE '1583-10-05' + INTERVAL 1
DAYS").returns(Date.valueOf("1583-10-06")).check();
---
assertQuery("SELECT TIMESTAMP '1583-10-01 00:00:00' + INTERVAL 1
DAYS").returns(Timestamp.valueOf("1583-10-02 00:00:00")).check();
{code}
The problem is in variation of date conversion in java.util.Date (used in
_TypeUtils#fromInterna()_). There is a threshold year 1582 (october) to
calculate in Gregorian calendar.
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1238
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c59dfd791f62d41f332db9e306bc1422/src/java.base/share/classes/java/util/Date.java#L1279
When Avatica does calculation in Julian calendar.
> Calcite. Incorrect processing of old date literals.
> ---
>
> Key: IGNITE-23772
> URL: https://issues.apache.org/jira/browse/IGNITE-23772
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: calcite, ignite-2, ise
>
> Consider:
> *1)* {code:java}
> assertQuery("SELECT DATE '1582-10-05'
[jira] [Updated] (IGNITE-24268) Minor refactoring in PartitionReplicaLifecycleManager
[ https://issues.apache.org/jira/browse/IGNITE-24268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtsev updated IGNITE-24268: - Description: This is a technical ticket for fixing minor issues that I stumbled upon while working with the code of PartitionReplicaLifecycleManager. (was: This is a technical ticket for fixing minor issues that I stumbled upon while working with the code of ) > Minor refactoring in PartitionReplicaLifecycleManager > - > > Key: IGNITE-24268 > URL: https://issues.apache.org/jira/browse/IGNITE-24268 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtsev >Assignee: Aleksandr Polovtsev >Priority: Trivial > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > This is a technical ticket for fixing minor issues that I stumbled upon while > working with the code of PartitionReplicaLifecycleManager. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24268) Minor refactoring in PartitionReplicaLifecycleManager
[ https://issues.apache.org/jira/browse/IGNITE-24268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtsev updated IGNITE-24268: - Description: This is a technical ticket for fixing minor issues that I stumbled upon while working with the code of > Minor refactoring in PartitionReplicaLifecycleManager > - > > Key: IGNITE-24268 > URL: https://issues.apache.org/jira/browse/IGNITE-24268 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtsev >Assignee: Aleksandr Polovtsev >Priority: Trivial > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > This is a technical ticket for fixing minor issues that I stumbled upon while > working with the code of -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24212) Non-persistent SQL schema isn't merged or validated when node joins cluster.
[ https://issues.apache.org/jira/browse/IGNITE-24212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-24212: -- Description: *Consider:* 1) There is a working non-persistent cluster with defined caches in _IgniteConfiguration_. 2) The caches have no SQL-entities set. 3) Node creates table over one of these cache with `_CREATE TABLE IF NOT EXISTS_`. A SQL table and a schema appear in the cluster. 4) One of the nodes restarts. 5) Next `_SELECT_` queries to the table may fail with '_TABLE NOT FOUND'_ 6) Restarted node has no tables in system view '_TABLES_'. *Cause:* The node restarts with defined cache configurations having no SQL entities set. When node joins cluster, dynamic tables/schema seem not merged or validated. The restarting node takes own cache configuration as is, without dynamically created schema and tables and has no the tables. +This works+ with the persistence because node stores and reads the cache meta holding the schema/entities. *Workarounds:* 1) Do not predefine caches, create them with `_CREATE TABLE_` 2) Set matching SQL entities in the predefined cache config. 3) Use other cache names with `_CREATE TABLE_` (_WITH "CACHE_NAME=._..). *Suggestions:* 1) Validate schema/caches and do not allow node join cluster. or 2) Merge static and dynamic schemas/cache configs and send them to the joining node. was: *Consider:* 1) There is a working non-persistent cluster with predefined caches in _IgniteConfiguration_. 2) The caches have no SQL-entities set. 3) A node creates a table over one of those cache with `_CREATE TABLE IF NOT EXISTS_`. A SQL table and a schema appear in the cluster. 4) One of the nodes restarts. 5) Next `_SELECT_` queries to the table may fail with '_TABLE NOT FOUND'_ 6) Restarted node has no tables in system view '_TABLES_'. *Cause:* The node restarts with predefined cache configuration having no SQL entities set. When node joins cluster, dynamic tables/schema seem not merged or validated. The restarting node takes the predefined cache configuration as is, without receiving the dynamically created schema and table. So, the node has no tables whereas the other cluster does. +This works+ with the persistence because node stores and reads the cache meta holding the schema/entities. *Workarounds:* 1) Do not predefine caches, create them with `_CREATE TABLE_` 2) Set matching SQL entities in the predefined cache config. 3) Use other cache names with `_CREATE TABLE_` (_WITH "CACHE_NAME=._..). *Suggestions:* 1) Validate schema/caches and do not allow node join cluster. or 2) Merge static and dynamic schemas/cache configs and send them to the joining node. > Non-persistent SQL schema isn't merged or validated when node joins cluster. > > > Key: IGNITE-24212 > URL: https://issues.apache.org/jira/browse/IGNITE-24212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14, 2.16 >Reporter: Vladimir Steshin >Priority: Minor > Labels: ise, sql > Attachments: TestNonPersistentNodeRestartsWithDynamicSQLTable.java > > > *Consider:* > 1) There is a working non-persistent cluster with defined caches in > _IgniteConfiguration_. > 2) The caches have no SQL-entities set. > 3) Node creates table over one of these cache with `_CREATE TABLE IF NOT > EXISTS_`. A SQL table and a schema appear in the cluster. > 4) One of the nodes restarts. > 5) Next `_SELECT_` queries to the table may fail with '_TABLE NOT FOUND'_ > 6) Restarted node has no tables in system view '_TABLES_'. > *Cause:* > The node restarts with defined cache configurations having no SQL entities > set. When node joins cluster, dynamic tables/schema seem not merged or > validated. The restarting node takes own cache configuration as is, without > dynamically created schema and tables and has no the tables. > +This works+ with the persistence because node stores and reads the cache > meta holding the schema/entities. > *Workarounds:* > 1) Do not predefine caches, create them with `_CREATE TABLE_` > 2) Set matching SQL entities in the predefined cache config. > 3) Use other cache names with `_CREATE TABLE_` (_WITH "CACHE_NAME=._..). > *Suggestions:* > 1) Validate schema/caches and do not allow node join cluster. > or > 2) Merge static and dynamic schemas/cache configs and send them to the > joining node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24277) Unchecked "log.debug" calls in storage code
Ivan Bessonov created IGNITE-24277:
--
Summary: Unchecked "log.debug" calls in storage code
Key: IGNITE-24277
URL: https://issues.apache.org/jira/browse/IGNITE-24277
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
These calls are mostly in {{{}PagesList{}}}. They lead to unnecessary vararg
arrays allocations on a hot path, which might negatively affect performance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24277) Unchecked "log.debug" calls in storage code
[
https://issues.apache.org/jira/browse/IGNITE-24277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-24277:
--
Assignee: Ivan Bessonov
> Unchecked "log.debug" calls in storage code
> ---
>
> Key: IGNITE-24277
> URL: https://issues.apache.org/jira/browse/IGNITE-24277
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>
> These calls are mostly in {{{}PagesList{}}}. They lead to unnecessary vararg
> arrays allocations on a hot path, which might negatively affect performance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24277) Unchecked "log.debug" calls in storage code
[
https://issues.apache.org/jira/browse/IGNITE-24277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-24277:
---
Labels: ignite-3 (was: )
> Unchecked "log.debug" calls in storage code
> ---
>
> Key: IGNITE-24277
> URL: https://issues.apache.org/jira/browse/IGNITE-24277
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These calls are mostly in {{{}PagesList{}}}. They lead to unnecessary vararg
> arrays allocations on a hot path, which might negatively affect performance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23999) Add support of CacheStore for AtomicSequence
[ https://issues.apache.org/jira/browse/IGNITE-23999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reassigned IGNITE-23999: -- Assignee: Ilya Shishkov > Add support of CacheStore for AtomicSequence > > > Key: IGNITE-23999 > URL: https://issues.apache.org/jira/browse/IGNITE-23999 > Project: Ignite > Issue Type: Improvement > Components: data structures >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > > Atomic data structures (eg., AtomicSequence) can be persistent only in case > of Ignite native persistence. It would be nice to have possibility to store > them into third party persistence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24239) Create stable reproducer for IGNITE-23588
[
https://issues.apache.org/jira/browse/IGNITE-24239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-24239:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Create stable reproducer for IGNITE-23588
> -
>
> Key: IGNITE-24239
> URL: https://issues.apache.org/jira/browse/IGNITE-24239
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Create a test that does the same thing as
> {{{}ItBplusTreePersistentPageMemoryTest#testMassiveRemove2_true{}}}, but with
> an execution order that 100% relies on a seed. This way all we need to do is
> find a single seed, and then the test will fail every time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24267) Reduce heap footprint for Lock manager
[
https://issues.apache.org/jira/browse/IGNITE-24267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-24267:
---
Description:
h3. Motivation
We preallocate much memory on the lock manager initialization.
{code}
locks = new ConcurrentHashMap<>(lockMapSize);
LockState[] tmp = new LockState[rawSlotsMaxSize];
for (int i = 0; i < tmp.length; i++) {
LockState lockState = new LockState();
if (i < lockMapSize) {
empty.add(lockState);
}
tmp[i] = lockState;
}
slots = tmp; // Atomic init.
{code}
was:
h3. Motivation
We preallocate much memory on the lock manager initialization.
{code}
locks = new ConcurrentHashMap<>(lockMapSize);
LockState[] tmp = new LockState[rawSlotsMaxSize];
for (int i = 0; i < tmp.length; i++) {
LockState lockState = new LockState();
if (i < lockMapSize) {
empty.add(lockState);
}
tmp[i] = lockState;
}
slots = tmp; // Atomic init.
{code}
> Reduce heap footprint for Lock manager
> --
>
> Key: IGNITE-24267
> URL: https://issues.apache.org/jira/browse/IGNITE-24267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> h3. Motivation
> We preallocate much memory on the lock manager initialization.
> {code}
> locks = new ConcurrentHashMap<>(lockMapSize);
> LockState[] tmp = new LockState[rawSlotsMaxSize];
> for (int i = 0; i < tmp.length; i++) {
> LockState lockState = new LockState();
> if (i < lockMapSize) {
> empty.add(lockState);
> }
> tmp[i] = lockState;
> }
> slots = tmp; // Atomic init.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24267) Reduce heap footprint for Lock manager
[
https://issues.apache.org/jira/browse/IGNITE-24267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-24267:
---
Labels: ignite-3 (was: )
> Reduce heap footprint for Lock manager
> --
>
> Key: IGNITE-24267
> URL: https://issues.apache.org/jira/browse/IGNITE-24267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We preallocate much memory on the lock manager initialization.
> {code}
> locks = new ConcurrentHashMap<>(lockMapSize);
> LockState[] tmp = new LockState[rawSlotsMaxSize];
> for (int i = 0; i < tmp.length; i++) {
> LockState lockState = new LockState();
> if (i < lockMapSize) {
> empty.add(lockState);
> }
> tmp[i] = lockState;
> }
> slots = tmp; // Atomic init.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24267) Reduce heap footprint for Lock manager
[
https://issues.apache.org/jira/browse/IGNITE-24267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-24267:
---
Description:
h3. Motivation
We preallocate much memory on the lock manager initialization.
{code}
locks = new ConcurrentHashMap<>(lockMapSize);
LockState[] tmp = new LockState[rawSlotsMaxSize];
for (int i = 0; i < tmp.length; i++) {
LockState lockState = new LockState();
if (i < lockMapSize) {
empty.add(lockState);
}
tmp[i] = lockState;
}
slots = tmp; // Atomic init.
{code}
Currently, the value {{rawSlotsMaxSize}} is about 1M. It takes about 100 MB for
the entire heap lock manager.
h3. Definition of done
Reduce heap size for the heap lock manager.
was:
h3. Motivation
We preallocate much memory on the lock manager initialization.
{code}
locks = new ConcurrentHashMap<>(lockMapSize);
LockState[] tmp = new LockState[rawSlotsMaxSize];
for (int i = 0; i < tmp.length; i++) {
LockState lockState = new LockState();
if (i < lockMapSize) {
empty.add(lockState);
}
tmp[i] = lockState;
}
slots = tmp; // Atomic init.
{code}
> Reduce heap footprint for Lock manager
> --
>
> Key: IGNITE-24267
> URL: https://issues.apache.org/jira/browse/IGNITE-24267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We preallocate much memory on the lock manager initialization.
> {code}
> locks = new ConcurrentHashMap<>(lockMapSize);
> LockState[] tmp = new LockState[rawSlotsMaxSize];
> for (int i = 0; i < tmp.length; i++) {
> LockState lockState = new LockState();
> if (i < lockMapSize) {
> empty.add(lockState);
> }
> tmp[i] = lockState;
> }
> slots = tmp; // Atomic init.
> {code}
> Currently, the value {{rawSlotsMaxSize}} is about 1M. It takes about 100 MB
> for the entire heap lock manager.
> h3. Definition of done
> Reduce heap size for the heap lock manager.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24270) Change IdleVerifyResult output
[ https://issues.apache.org/jira/browse/IGNITE-24270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-24270: - Labels: ise (was: IEP-132 ise) > Change IdleVerifyResult output > --- > > Key: IGNITE-24270 > URL: https://issues.apache.org/jira/browse/IGNITE-24270 > Project: Ignite > Issue Type: Task >Reporter: Maksim Davydov >Priority: Trivial > Labels: ise > > IdleVerifyResult#printConflicts(Consumer) output depends on > code-specific class naming, like PartitionKey#toString(), and > PartitionHashRecord#toString() > It's better to change the output, so that the IdleVerify command output > doesn't depend on class naming -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24270) Change IdleVerifyResult output
[ https://issues.apache.org/jira/browse/IGNITE-24270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-24270: - Labels: IEP-132 ise (was: ise) > Change IdleVerifyResult output > --- > > Key: IGNITE-24270 > URL: https://issues.apache.org/jira/browse/IGNITE-24270 > Project: Ignite > Issue Type: Task >Reporter: Maksim Davydov >Priority: Trivial > Labels: IEP-132, ise > > IdleVerifyResult#printConflicts(Consumer) output depends on > code-specific class naming, like PartitionKey#toString(), and > PartitionHashRecord#toString() > It's better to change the output, so that the IdleVerify command output > doesn't depend on class naming -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24031) Sql schema. Extend IgniteCatalog API with supporting qualified names.
[
https://issues.apache.org/jira/browse/IGNITE-24031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-24031:
Fix Version/s: 3.1
(was: 3.0)
> Sql schema. Extend IgniteCatalog API with supporting qualified names.
> -
>
> Key: IGNITE-24031
> URL: https://issues.apache.org/jira/browse/IGNITE-24031
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Pereslegin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Extend {{IgniteCatalog}} interface with methods for creating/dropping
> schemas, and fix table methods signatures, which require table name.
> {code:java}
> interface IgniteCatalog {
> TableDefinition tableDefinition(QualifiedName tableName);
> void dropTable(QualifiedName tableName);
> /* Existing methods should become shoutcuts to a new ones. */
> TableDefinition tableDefinition(String tableName);
> void dropTable(String tableName);
> }
> {code}
> The methods that create TableDefinition, which accept String parameters, are
> shortcuts to the new ones.
> String tablenames must satisfy QualifiedName.parse() parameter format.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21663) Cluster load balancing when 1 node is killed doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21663:
Fix Version/s: 3.0
(was: 3.1)
> Cluster load balancing when 1 node is killed doesn't work
> -
>
> Key: IGNITE-21663
> URL: https://issues.apache.org/jira/browse/IGNITE-21663
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Affects Versions: 3.0.0-beta1
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Steps to reproduce:*
> # Start cluster with 2 nodes running locally.
> # Make connection like this:
> {code:java}
> try (IgniteClient igniteClient = IgniteClient.builder().retryPolicy(new
> RetryLimitPolicy()).addresses(thinClientEndpoints.toArray(new
> String[]{"localhost:10800","localhost:10801"})).build()) {
> try (Session session = igniteClient.sql().createSession()) {
> //code here
> }
> } {code}
> 3. Create table with replication 2
> 4. Execute insert 1 row and select from the table.
> 5. Kill first node (in list of connection)
> 6. Execute select from the table.
> *Expected:*
> Cluster works with one node.
> *Actual:*
> The exception on select after first node is killed, the select is not
> executed.
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:92e48867-2e6e-4730-9781-527a4e204b32 Unable to send fragment
> [targetNode=ConnectionTest_cluster_0, fragmentId=1,
> cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /192.168.100.5:3344]
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.lambda$executeQuery$0(ThinClientSteps.java:61)
> at io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at io.qameta.allure.Allure.step(Allure.java:181)
> at io.qameta.allure.Allure.step(Allure.java:125)
> at
> org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.executeQuery(ThinClientSteps.java:61)
> at
> org.gridgain.ai3tests.tests.ConnectionTest.testThinClientConnectionToMultipleHost(ConnectionTest.java:93)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:92e48867-2e6e-4730-9781-527a4e204b32 Unable to send fragment
> [targetNode=ConnectionTest_cluster_0, fragmentId=1,
> cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /192.168.100.5:3344]
> 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.uniWhenComplete(CompletableFuture.java:870)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:419)
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:238)
> at
> java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.base/java.util.concurrent.F
[jira] [Updated] (IGNITE-23466) Refactor DZM internals
[ https://issues.apache.org/jira/browse/IGNITE-23466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-23466: Fix Version/s: 3.1 (was: 3.0) > Refactor DZM internals > -- > > Key: IGNITE-23466 > URL: https://issues.apache.org/jira/browse/IGNITE-23466 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, important > Fix For: 3.1 > > > h3. Motivation > In order to simply DistributionZone dataNodes processing and meet meta > storage compaction requirements it's required not to use MG versioning. > Generally following logic should be implemented. > * On topology event > ** Check whether we already have corresponding pending scaleUp/Down timer. > If not: > *** Serialised timer is written to MG synchronously. In timer's data bag > it's expected to have > Awake/DataNodes atomic switch timestamp. > Data nodes to apply. > *** Else: > Rewrite existing timer by updating Awake/DataNodes timestamp along with > data nodes to apply. That should be done atomically in a way that calculated > topology event timestamp is used while comparison with already existing awake > one. > ** Timer is scheduled. > * On timer > ** Atomically remove the timer and set add new timestamp -> dataNodes entry > in dataNodes map in MG and DZM volatile cache. > * On node restart: > ** restore corresponding volatile state from the MG. > * On filter change: > ** Immediately trigger on timer. > * On timeout adjustments > ** Rewrite existing timers if exists. > There's a chance that topology and node attributes should also be internally > versioned. > h3. Definition of Done > * DZM manages dataNodes and related history internally in last MG key like > Catalog does. > * New robust mechanic of atomic timers to dataNodes application is used. > Details are described in Motivation section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23561) Refactor DZM dataNodes processing
[ https://issues.apache.org/jira/browse/IGNITE-23561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-23561: Fix Version/s: 3.1 (was: 3.0) > Refactor DZM dataNodes processing > - > > Key: IGNITE-23561 > URL: https://issues.apache.org/jira/browse/IGNITE-23561 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, important > Fix For: 3.1 > > > h3. Motivation > see https://issues.apache.org/jira/browse/IGNITE-23466 > * On dataNodes(timerstamp, zone). Yep, dataNodes() should be refactored in > order to use timestamp instead of revision, catalog version: > ** check whether there's nonAwaked timers with awakeTimestamp less or equal > to the requested one. If true - "fire" the timer. > ** Iterate over existing timestamp -> dataNodes entries and find closest one > to the left. > h3. Definition of Done > * DZM dataNodes() uses HybridTimestamp instead of MG revision and catalog > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20166) Metastorage Compaction
[ https://issues.apache.org/jira/browse/IGNITE-20166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20166: Fix Version/s: 3.1 (was: 3.0) > Metastorage Compaction > -- > > Key: IGNITE-20166 > URL: https://issues.apache.org/jira/browse/IGNITE-20166 > Project: Ignite > Issue Type: Epic >Reporter: Sergey Chugunov >Priority: Major > Labels: ignite-3, important > Fix For: 3.1 > > > General logic of metastorage is that it supports multiple versions for the > same key corresponding to different timestamps. > At the same time there is a concept of a low watermark - a moment in time > when all timestamps falling below that mark become obsolete and can be pruned > from Metastorage. > We need to implement a mechanism to compact Metastorage to remove obsolete > keys. At the same time some components may rely on availability of history of > key's versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24206) Add index and term to RaftGroupConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-24206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-24206: - Description: h3. Motivation in order to track raft index and term on which configuration was applied to raft, we need to add index and term to RaftGroupConfiguration h3. Implementation notes In order to achieve that, we have to propagate cfg index and term to snapshot meta h3. Definition of done * Index and term are added to RaftGroupConfiguration was: h3. Motivation in order to track raft index and term on which configuration was applied to raft, we need to add index and term to RaftGroupConfiguration h3. Definition of done * Index and term are added to RaftGroupConfiguration > Add index and term to RaftGroupConfiguration > > > Key: IGNITE-24206 > URL: https://issues.apache.org/jira/browse/IGNITE-24206 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > in order to track raft index and term on which configuration was applied to > raft, we need to add index and term to RaftGroupConfiguration > h3. Implementation notes > In order to achieve that, we have to propagate cfg index and term to snapshot > meta > h3. Definition of done > * Index and term are added to RaftGroupConfiguration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24270) Change IdleVerifyResult output
Maksim Davydov created IGNITE-24270: --- Summary: Change IdleVerifyResult output Key: IGNITE-24270 URL: https://issues.apache.org/jira/browse/IGNITE-24270 Project: Ignite Issue Type: Task Reporter: Maksim Davydov IdleVerifyResult#printConflicts(Consumer) output depends on code-specific class naming, like PartitionKey#toString(), and PartitionHashRecord#toString() It's better to change the output, so that the IdleVerify command output doesn't depend on class naming -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24269) Flaky ItStatisticTest.testStatisticsRowCount test
[
https://issues.apache.org/jira/browse/IGNITE-24269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-24269:
Description:
We have periodically failed ItStatisticTest.testStatisticsRowCount test, which
seems became flaky after IGNITE-23968.
Need to investigate the root cause and fix it.
{code:java}
java.lang.AssertionError: Invalid plan:
Exchange(distribution=[single]): rowcount = 48.15, cumulative cost = IgniteCost
[rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0, network=385.2], id = 357882
TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
[rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
Expected: a string contains once ".*(Table|Index)Scan\\(table=\\[\\[PUBLIC,
T\\]\\].*\\]\\)\\:.*cumulative cost = IgniteCost \\[rowCount=500.0"
but: was "Exchange(distribution=[single]): rowcount = 48.15, cumulative
cost = IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0,
network=385.2], id = 357882
TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
[rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
"java.lang.AssertionError: Invalid plan:Exchange(distribution=[single]):
rowcount = 48.15, cumulative cost = IgniteCost [rowCount=369.15, cpu=1332.15,
memory=0.0, io=0.0, network=385.2], id = 357882 TableScan(table=[[PUBLIC, T]],
tableId=[16], filters=[=($t1, 502)], requiredColumns=[{0, 1}]): rowcount =
48.15, cumulative cost = IgniteCost [rowCount=321.0, cpu=1284.0, memory=0.0,
io=0.0, network=0.0], id = 357881Expected: a string contains once
".*(Table|Index)Scan\\(table=\\[\\[PUBLIC, T\\]\\].*\\]\\)\\:.*cumulative cost
= IgniteCost \\[rowCount=500.0" but: was "Exchange(distribution=[single]):
rowcount = 48.15, cumulative cost = IgniteCost [rowCount=369.15, cpu=1332.15,
memory=0.0, io=0.0, network=385.2], id = 357882 TableScan(table=[[PUBLIC, T]],
tableId=[16], filters=[=($t1, 502)], requiredColumns=[{0, 1}]): rowcount =
48.15, cumulative cost = IgniteCost [rowCount=321.0, cpu=1284.0, memory=0.0,
io=0.0, network=0.0], id = 357881" {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8798092]
was:
We have periodically failed ItStatisticTest.testStatisticsRowCount test, which
seems became flaky after IGNITE-23968.
Need to investigate the root cause and fix it.
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8798092
> Flaky ItStatisticTest.testStatisticsRowCount test
> -
>
> Key: IGNITE-24269
> URL: https://issues.apache.org/jira/browse/IGNITE-24269
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We have periodically failed ItStatisticTest.testStatisticsRowCount test,
> which seems became flaky after IGNITE-23968.
> Need to investigate the root cause and fix it.
> {code:java}
> java.lang.AssertionError: Invalid plan:
> Exchange(distribution=[single]): rowcount = 48.15, cumulative cost =
> IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0, network=385.2],
> id = 357882
> TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
> requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
> [rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
> Expected: a string contains once ".*(Table|Index)Scan\\(table=\\[\\[PUBLIC,
> T\\]\\].*\\]\\)\\:.*cumulative cost = IgniteCost \\[rowCount=500.0"
> but: was "Exchange(distribution=[single]): rowcount = 48.15, cumulative
> cost = IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0,
> network=385.2], id = 357882
> TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
> requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
> [rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
> "java.lang.AssertionError: Invalid plan:Exchange(distribution=[single]):
> rowcount = 48.15, cumulative cost = IgniteCost [rowCount=369.15, cpu=1332.15,
> memory=0.0, io=0.0, network=385.2], id = 357882 TableScan(table=[[PUBLIC,
> T]], tableId=[16], filters=[=($t1, 502)], requiredColumns=[{0, 1}]): rowcount
> = 48.15, cumulative cost = IgniteCost [rowCount=321.0, cpu=1284.0,
> memory=0.0, io=0.0, network=0.0], id = 357881Expected: a string contains once
> ".*(Table|Index)Scan\\(table=\\[\\[PUBLIC, T\\]\\].*\\]\\)\\:.*cumulative
> cost = IgniteCost \\[rowCount=500.0" but: was
> "Exchange(distribution=[single]): rowcount = 48.15, cumulative cost =
> IgniteCost [rowCount=
[jira] [Updated] (IGNITE-24269) Flaky ItStatisticTest.testStatisticsRowCount test
[ https://issues.apache.org/jira/browse/IGNITE-24269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-24269: Component/s: sql > Flaky ItStatisticTest.testStatisticsRowCount test > - > > Key: IGNITE-24269 > URL: https://issues.apache.org/jira/browse/IGNITE-24269 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We have periodically failed ItStatisticTest.testStatisticsRowCount test, > which seems became flaky after IGNITE-23968. > Need to investigate the root cause and fix it. > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8798092 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24238) ItIgniteDistributionZoneManagerNodeRestartTest#testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful
[
https://issues.apache.org/jira/browse/IGNITE-24238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev reassigned IGNITE-24238:
Assignee: Aleksandr Polovtsev
> ItIgniteDistributionZoneManagerNodeRestartTest#testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful
>
> ---
>
> Key: IGNITE-24238
> URL: https://issues.apache.org/jira/browse/IGNITE-24238
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> {{ItIgniteDistributionZoneManagerNodeRestartTest#testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful}}
> is flaky with
> {noformat}
> org.mockito.exceptions.misusing.UnfinishedStubbingException:
> Unfinished stubbing detected here:
> -> at
> org.apache.ignite.internal.distributionzones.ItIgniteDistributionZoneManagerNodeRestartTest.testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful(ItIgniteDistributionZoneManagerNodeRestartTest.java:642)
> E.g. thenReturn() may be missing.
> Examples of correct stubbing:
> when(mock.isOk()).thenReturn(true);
> when(mock.isOk()).thenThrow(exception);
> doThrow(exception).when(mock).someVoidMethod();
> Hints:
> 1. missing thenReturn()
> 2. you are trying to stub a final method, which is not supported
> 3. you are stubbing the behaviour of another mock inside before 'thenReturn'
> instruction is completed
> org.mockito.exceptions.misusing.UnfinishedStubbingException:
> Unfinished stubbing detected here:
> -> at
> org.apache.ignite.internal.distributionzones.ItIgniteDistributionZoneManagerNodeRestartTest.testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful(ItIgniteDistributionZoneManagerNodeRestartTest.java:642)
> E.g. thenReturn() may be missing.
> Examples of correct stubbing:
> when(mock.isOk()).thenReturn(true);
> when(mock.isOk()).thenThrow(exception);
> doThrow(exception).when(mock).someVoidMethod();
> Hints:
> 1. missing thenReturn()
> 2. you are trying to stub a final method, which is not supported
> 3. you are stubbing the behaviour of another mock inside before 'thenReturn'
> instruction is completed
> at
> app//org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.invoke(MetaStorageManagerImpl.java:991)
> at
> app//org.apache.ignite.internal.distributionzones.ItIgniteDistributionZoneManagerNodeRestartTest.testCreationZoneWhenDataNodesAreDeletedIsNotSuccessful(ItIgniteDistributionZoneManagerNodeRestartTest.java:651)
> at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> {noformat}
> It seems that we have some concurrent access to MS that is supposed to be
> stubed.
> Form Mockito docs:
> {noformat}
> However Mockito is only thread-safe in healthy tests, that is tests without
> multiple threads stubbing/verifying a shared mock.
> Stubbing or verification of a shared mock from different threads is NOT the
> proper way of testing because it will always lead to intermittent behavior.
> In general, mutable state + assertions in multi-threaded environment lead to
> random results.
> If you do stub/verify a shared mock across threads you will face occasional
> exceptions like: WrongTypeOfReturnValue, etc.*
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24273) Investigate flaky ItNodeTest#testInstallSnapshot
Kirill Tkalenko created IGNITE-24273:
Summary: Investigate flaky ItNodeTest#testInstallSnapshot
Key: IGNITE-24273
URL: https://issues.apache.org/jira/browse/IGNITE-24273
Project: Ignite
Issue Type: Task
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
We need to deal with flaky
*org.apache.ignite.raft.jraft.core.ItNodeTest#testInstallSnapshot*.
Link to
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=8794190&buildTypeId=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRaft&tab=buildResultsDiv].
{noformat}
org.opentest4j.AssertionFailedError: expected: <2> but was: <1>
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.AssertEquals.failNotEqual(AssertEquals.java:197)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.triggerLeaderSnapshot(ItNodeTest.java:4635)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testInstallSnapshot(ItNodeTest.java:2274)
at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24242) Add Configuration keys for Transaction Timeout
[
https://issues.apache.org/jira/browse/IGNITE-24242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-24242:
-
Labels: ignite-3 (was: )
> Add Configuration keys for Transaction Timeout
> --
>
> Key: IGNITE-24242
> URL: https://issues.apache.org/jira/browse/IGNITE-24242
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> transaction.roTimeout and transaction.rwTimeout should be added. Also, the
> following configuration keys might be added:
> transaction: {
> minRoTimeout, maxRoTimeout, minRwTimeout, maxRwTimeout
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24246) Benchmarks for Transaction Timeout
[ https://issues.apache.org/jira/browse/IGNITE-24246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24246: - Labels: ignite-3 (was: ) > Benchmarks for Transaction Timeout > -- > > Key: IGNITE-24246 > URL: https://issues.apache.org/jira/browse/IGNITE-24246 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > The "tracking" of transactions must not introduce any performance > degradation. Benchmarks should prove that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24245) Introduce a error code for Transaction Timeout.
[ https://issues.apache.org/jira/browse/IGNITE-24245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24245: - Labels: ignite-3 (was: ) > Introduce a error code for Transaction Timeout. > > > Key: IGNITE-24245 > URL: https://issues.apache.org/jira/browse/IGNITE-24245 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > TransactionException is thrown with the corresponding message and error code > TX_TIMEOUT_EXCEEDED. The exception is the same as we throw for finished > transactions but for different reasons. > The “reason” is held in TxMeta.reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24244) Track Rw transactions timeout
[ https://issues.apache.org/jira/browse/IGNITE-24244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24244: - Labels: ignite-3 (was: ) > Track Rw transactions timeout > - > > Key: IGNITE-24244 > URL: https://issues.apache.org/jira/browse/IGNITE-24244 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > TransactionExpirationRegistry is used to track Ro transactions. Rw should be > tracked there as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24243) SQL: query_timeout should be used as transaction timeout
[ https://issues.apache.org/jira/browse/IGNITE-24243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24243: - Labels: ignite-3 (was: ) > SQL: query_timeout should be used as transaction timeout > > > Key: IGNITE-24243 > URL: https://issues.apache.org/jira/browse/IGNITE-24243 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > In SQL query_timeout can be re-used for the transaction timeout. This > property is already used for the query timeout. The only thing that should be > done is to set the query_timeout as the transaction timeout for the > transaction that is started implicitly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24088) Introduce chain and link abstractions
[ https://issues.apache.org/jira/browse/IGNITE-24088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24088: - Labels: ignite-3 (was: ) > Introduce chain and link abstractions > - > > Key: IGNITE-24088 > URL: https://issues.apache.org/jira/browse/IGNITE-24088 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24029) Sql schema. Extend Table API with supporting qualified names.
[
https://issues.apache.org/jira/browse/IGNITE-24029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-24029:
--
Description:
It is necessary to introduce new methods in IgniteTables that use
{{QualifiedName}} instead of simple String.
And change the old ones to use the new ones using the helper method
{{{}QualifiedName.parseof(String){}}}.
{code:java}
interface IgniteTables {
/** Gets a list of all tables */
List tables();
/** Gets a list of tables that belong to requested schema. */
List tables(String schemaName); // optional
/** Gets a table with specified name. */
@Nullable Table table(QualifiedName tableName);
@Nullable Table table(String tableName) {
return table(QualifiedName.parseof(tableName));
}
/* ... + async methods ... */
}
public interface Table {
/** Returns table's qualified name. */
QualifiedName tableName();
}
{code}
Add integration tests, which checks cache names are correctly resolved.
Add table::name that returns a QualifiedName.
was:
It is necessary to introduce new methods in IgniteTables that use
{{QualifiedName}} instead of simple String.
And change the old ones to use the new ones using the helper method
{{{}QualifiedName.parseof(String){}}}.
{code:java}
interface IgniteTables {
/** Gets a list of all tables */
List tables();
/** Gets a list of tables that belong to requested schema. */
List tables(String schemaName); // optional
/** Gets a table with specified name. */
@Nullable Table table(QualifiedName tableName);
@Nullable Table table(String tableName) {
return table(QualifiedName.parseof(tableName));
}
/* ... + async methods ... */
}
public interface Table {
/** Returns table's qualified name. */
QualifiedName tableName();
}
{code}
Add integration tests, which checks cache names are correctly resolved.
Add table::name that returns a QualifiedName.
Mark table::name that returns a string as deprecated.
> Sql schema. Extend Table API with supporting qualified names.
> -
>
> Key: IGNITE-24029
> URL: https://issues.apache.org/jira/browse/IGNITE-24029
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is necessary to introduce new methods in IgniteTables that use
> {{QualifiedName}} instead of simple String.
> And change the old ones to use the new ones using the helper method
> {{{}QualifiedName.parseof(String){}}}.
> {code:java}
> interface IgniteTables {
> /** Gets a list of all tables */
> List tables();
> /** Gets a list of tables that belong to requested schema. */
> List tables(String schemaName); // optional
> /** Gets a table with specified name. */
> @Nullable Table table(QualifiedName tableName);
> @Nullable Table table(String tableName) {
> return table(QualifiedName.parseof(tableName));
> }
> /* ... + async methods ... */
> }
> public interface Table {
> /** Returns table's qualified name. */
> QualifiedName tableName();
> }
> {code}
> Add integration tests, which checks cache names are correctly resolved.
> Add table::name that returns a QualifiedName.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24269) Flaky ItStatisticTest.testStatisticsRowCount test
Iurii Gerzhedovich created IGNITE-24269: --- Summary: Flaky ItStatisticTest.testStatisticsRowCount test Key: IGNITE-24269 URL: https://issues.apache.org/jira/browse/IGNITE-24269 Project: Ignite Issue Type: Bug Reporter: Iurii Gerzhedovich We have periodically failed ItStatisticTest.testStatisticsRowCount test, which seems became flaky after IGNITE-23968. Need to investigate the root cause and fix it. https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8798092 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24029) Sql schema. Extend Table API with supporting qualified names.
[
https://issues.apache.org/jira/browse/IGNITE-24029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-24029:
Fix Version/s: 3.0
> Sql schema. Extend Table API with supporting qualified names.
> -
>
> Key: IGNITE-24029
> URL: https://issues.apache.org/jira/browse/IGNITE-24029
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is necessary to introduce new methods in IgniteTables that use
> {{QualifiedName}} instead of simple String.
> And change the old ones to use the new ones using the helper method
> {{{}QualifiedName.parseof(String){}}}.
> {code:java}
> interface IgniteTables {
> /** Gets a list of all tables */
> List tables();
> /** Gets a list of tables that belong to requested schema. */
> List tables(String schemaName); // optional
> /** Gets a table with specified name. */
> @Nullable Table table(QualifiedName tableName);
> @Nullable Table table(String tableName) {
> return table(QualifiedName.parseof(tableName));
> }
> /* ... + async methods ... */
> }
> public interface Table {
> /** Returns table's qualified name. */
> QualifiedName tableName();
> }
> {code}
> Add integration tests, which checks cache names are correctly resolved.
> Add table::name that returns a QualifiedName.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24269) Flaky ItStatisticTest.testStatisticsRowCount test
[
https://issues.apache.org/jira/browse/IGNITE-24269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-24269:
-
Assignee: Konstantin Orlov
> Flaky ItStatisticTest.testStatisticsRowCount test
> -
>
> Key: IGNITE-24269
> URL: https://issues.apache.org/jira/browse/IGNITE-24269
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> We have periodically failed ItStatisticTest.testStatisticsRowCount test,
> which seems became flaky after IGNITE-23968.
> Need to investigate the root cause and fix it.
> {code:java}
> java.lang.AssertionError: Invalid plan:
> Exchange(distribution=[single]): rowcount = 48.15, cumulative cost =
> IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0, network=385.2],
> id = 357882
> TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
> requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
> [rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
> Expected: a string contains once ".*(Table|Index)Scan\\(table=\\[\\[PUBLIC,
> T\\]\\].*\\]\\)\\:.*cumulative cost = IgniteCost \\[rowCount=500.0"
> but: was "Exchange(distribution=[single]): rowcount = 48.15, cumulative
> cost = IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0,
> network=385.2], id = 357882
> TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1, 502)],
> requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost = IgniteCost
> [rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id = 357881
> "java.lang.AssertionError: Invalid plan:Exchange(distribution=[single]):
> rowcount = 48.15, cumulative cost = IgniteCost [rowCount=369.15, cpu=1332.15,
> memory=0.0, io=0.0, network=385.2], id = 357882 TableScan(table=[[PUBLIC,
> T]], tableId=[16], filters=[=($t1, 502)], requiredColumns=[{0, 1}]): rowcount
> = 48.15, cumulative cost = IgniteCost [rowCount=321.0, cpu=1284.0,
> memory=0.0, io=0.0, network=0.0], id = 357881Expected: a string contains once
> ".*(Table|Index)Scan\\(table=\\[\\[PUBLIC, T\\]\\].*\\]\\)\\:.*cumulative
> cost = IgniteCost \\[rowCount=500.0" but: was
> "Exchange(distribution=[single]): rowcount = 48.15, cumulative cost =
> IgniteCost [rowCount=369.15, cpu=1332.15, memory=0.0, io=0.0, network=385.2],
> id = 357882 TableScan(table=[[PUBLIC, T]], tableId=[16], filters=[=($t1,
> 502)], requiredColumns=[{0, 1}]): rowcount = 48.15, cumulative cost =
> IgniteCost [rowCount=321.0, cpu=1284.0, memory=0.0, io=0.0, network=0.0], id
> = 357881" {code}
>
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8798092]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24178) Remove idleVerifyV1 related code
[ https://issues.apache.org/jira/browse/IGNITE-24178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914958#comment-17914958 ] Maksim Davydov commented on IGNITE-24178: - https://tcbot2.sbt-ignite-dev.ru/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/11801/head&action=Latest > Remove idleVerifyV1 related code > > > Key: IGNITE-24178 > URL: https://issues.apache.org/jira/browse/IGNITE-24178 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Davydov >Assignee: Maksim Davydov >Priority: Major > Labels: IEP-132, ise > Time Spent: 50m > Remaining Estimate: 0h > > The code related to the old idleVerifyV1 task is still present in the code > base. Since it is not used the classes like > RetrieveConflictPartitionValuesTask, CollectConflictPartitionKeysTask, and > related code need to be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24274) Sql. Inbox push throws Assertion error when called after Inbox close
Maksim Zhuravkov created IGNITE-24274: - Summary: Sql. Inbox push throws Assertion error when called after Inbox close Key: IGNITE-24274 URL: https://issues.apache.org/jira/browse/IGNITE-24274 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov Inbox operator does not handle closing properly, because it is possible to invoke Inbox close, then to get a queued call to Inbox doPush and get AssertionError as a result. Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that cancels a DML query during execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24274) Sql. Inbox push throws AssertionError when called after Inbox close
[ https://issues.apache.org/jira/browse/IGNITE-24274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-24274: -- Summary: Sql. Inbox push throws AssertionError when called after Inbox close (was: Sql. Inbox push throws Assertion error when called after Inbox close) > Sql. Inbox push throws AssertionError when called after Inbox close > --- > > Key: IGNITE-24274 > URL: https://issues.apache.org/jira/browse/IGNITE-24274 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Inbox operator does not handle closing properly, because it is possible to > invoke Inbox close, then to get a queued call to Inbox doPush and get an > AssertionError. > Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that > cancels a DML query during execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24274) Sql. Inbox push throws Assertion error when called after Inbox close
[ https://issues.apache.org/jira/browse/IGNITE-24274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-24274: -- Description: Inbox operator does not handle closing properly, because it is possible to invoke Inbox close, then to get a queued call to Inbox doPush and get an AssertionError. Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that cancels a DML query during execution. was: Inbox operator does not handle closing properly, because it is possible to invoke Inbox close, then to get a queued call to Inbox doPush and get AssertionError as a result. Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that cancels a DML query during execution. > Sql. Inbox push throws Assertion error when called after Inbox close > > > Key: IGNITE-24274 > URL: https://issues.apache.org/jira/browse/IGNITE-24274 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Inbox operator does not handle closing properly, because it is possible to > invoke Inbox close, then to get a queued call to Inbox doPush and get an > AssertionError. > Can be reproduced by ItSqlSynchronousApiTest cancelLongRunningStatement that > cancels a DML query during execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24224) Broken serialization of communication messages in cluster with SSL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-24224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-24224:
-
Fix Version/s: 2.17
> Broken serialization of communication messages in cluster with SSL enabled.
> ---
>
> Key: IGNITE-24224
> URL: https://issues.apache.org/jira/browse/IGNITE-24224
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Blocker
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following code can be considered as a reproducer of the problem.
> Its main goal is to cause Ignite to be overloaded with communication
> messages. In this particular case it will be GridJobExecuteRequest and
> GridJobExecuteResponce spamming.
> {code:java}
> /** */
> public class BrokenSerializationTest extends AbstractSecurityTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> SslContextFactory factory =
> (SslContextFactory)sslTrustedFactory("server", "trustone");
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName)
> .setSslContextFactory(factory)
> .setFailureHandler(new StopNodeOrHaltFailureHandler());
> cfg.setCommunicationSpi(new
> TcpCommunicationSpi().setUnacknowledgedMessagesBufferSize(160)); // Small
> values of this property causes Ignite to frequently reestablish connection
> between nodes.
> return cfg;
> }
> /** Tests task execution security context in case task was initiated from
> the {@link IgniteClient}. */
> @Test
> public void test() throws Exception {
> IgniteEx ignite = startGridAllowAll("crd");
> startGridAllowAll("srv1");
> startGridAllowAll("srv2");
> startGridAllowAll("srv3");
> startGridAllowAll("srv4");
> startGridAllowAll("srv5");
> awaitPartitionMapExchange();
> Set errors = ConcurrentHashMap.newKeySet();
> Set> futs = ConcurrentHashMap.newKeySet();
> CountDownLatch latch = new CountDownLatch(16 * 1);
> for (int i = 0; i < 16; i++) {
> GridTestUtils.runAsync(() -> {
> try {
> U.sleep(1000);
> for (int j = 0; j < 1; j++) {
> futs.add(ignite.context().task(). Integer>execute(
> TestTask.class.getName(),
> null,
>
> TaskExecutionOptions.options().asPublicRequest().withProjection(ignite.cluster().nodes())
> ).publicFuture());
> latch.countDown();
> }
> }
> catch (Throwable e) {
> errors.add(e);
> }
> });
> }
> latch.await(getTestTimeout(), TimeUnit.MILLISECONDS);
> assertTrue(errors.isEmpty());
> for (ComputeTaskFuture fut : futs) {
> assertTrue(null == fut.get(getTestTimeout()));
> }
> }
> /** */
> public static class TestTask implements ComputeTask {
> /** {@inheritDoc} */
> @Override public @NotNull Map map(
> List subgrid,
> @Nullable Void arg
> ) throws IgniteException {
> Map res = new HashMap<>();
> for (ClusterNode node : subgrid) {
> res.put(new ComputeJob() {
> @Override public void cancel() {
> // No-op.
> }
> @Override public Object execute() throws IgniteException {
> return null;
> }
> }, node);
> }
> return res;
> }
> /** {@inheritDoc} */
> @Override public ComputeJobResultPolicy result(ComputeJobResult res,
> List rcvd) {
> if (res.getException() != null)
> throw new IgniteException(res.getException());
> return ComputeJobResultPolicy.WAIT;
> }
> /** {@inheritDoc} */
> @Override public @Nullable Integer reduce(List
> results) throws IgniteException {
> assertEquals(allGrids().size(), results.size());
> return null;
> }
> }
> }
> {code}
> It does not reproduce the problem sequentially because the problem is related
> to cases when only part of the message is read into the application buffer
> while reading from the socket.
> While this reproducer is in progress you can witness different errors related
> to communication message handling e.g.
> {code:java}
[jira] [Updated] (IGNITE-24095) Remove FORCE_AFF_REASSIGNMENT_SINCE
[ https://issues.apache.org/jira/browse/IGNITE-24095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Novikov updated IGNITE-24095: --- Fix Version/s: 2.18 > Remove FORCE_AFF_REASSIGNMENT_SINCE > --- > > Key: IGNITE-24095 > URL: https://issues.apache.org/jira/browse/IGNITE-24095 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Vladislav Novikov >Priority: Major > Labels: IEP-132, ise > Fix For: 2.18 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
