[jira] [Updated] (IGNITE-15753) [Extensions] Add compatibility tests for Ignite Spring cache and tx extensions.
[ https://issues.apache.org/jira/browse/IGNITE-15753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15753: - Component/s: extensions > [Extensions] Add compatibility tests for Ignite Spring cache and tx > extensions. > --- > > Key: IGNITE-15753 > URL: https://issues.apache.org/jira/browse/IGNITE-15753 > Project: Ignite > Issue Type: Improvement > Components: extensions >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > It is needed to add compatibility tests for Ignite Spring extensions that > will test extensions against different versions of Ignite and Spring. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15814) [Native Persistence 3.0] Data Structures porting
[ https://issues.apache.org/jira/browse/IGNITE-15814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-15814: - Ignite Flags: (was: Docs Required,Release Notes Required) > [Native Persistence 3.0] Data Structures porting > - > > Key: IGNITE-15814 > URL: https://issues.apache.org/jira/browse/IGNITE-15814 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > h2. Goal > In Ignite 3 we'll reuse basic data structures from Ignite 2 persistence > codebase, but need to fix some design flaws and remove dependencies from WAL > logging functionality as in Ignite 3 WAL is an external service. > h2. Items to pay attention to > Port data structures classes hierarchy: AbstraceDataStructure, -BPlusTree- > and FreeList implementations (some implementations may not be necessary, they > should be considered individually). > Port existing unit tests whenever it doesn't require too much effort. > Type parameters clarification in data structures is needed. > h2. More details > I think this issue should be concentrated on porting of Free List rather than > BPlusTree. Maybe classes like Storable should be revisited. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15814) [Native Persistence 3.0] Data Structures porting
[ https://issues.apache.org/jira/browse/IGNITE-15814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-15814: - Fix Version/s: 3.0.0-alpha5 > [Native Persistence 3.0] Data Structures porting > - > > Key: IGNITE-15814 > URL: https://issues.apache.org/jira/browse/IGNITE-15814 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > h2. Goal > In Ignite 3 we'll reuse basic data structures from Ignite 2 persistence > codebase, but need to fix some design flaws and remove dependencies from WAL > logging functionality as in Ignite 3 WAL is an external service. > h2. Items to pay attention to > Port data structures classes hierarchy: AbstraceDataStructure, -BPlusTree- > and FreeList implementations (some implementations may not be necessary, they > should be considered individually). > Port existing unit tests whenever it doesn't require too much effort. > Type parameters clarification in data structures is needed. > h2. More details > I think this issue should be concentrated on porting of Free List rather than > BPlusTree. Maybe classes like Storable should be revisited. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16414: --- Labels: calcite2-required calcite3-required (was: ) > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
Aleksey Plekhanov created IGNITE-16414: -- Summary: Calcite engine. Sorted index spool produces wrong collation Key: IGNITE-16414 URL: https://issues.apache.org/jira/browse/IGNITE-16414 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov The sorted index spool does not take into account input collation directions and null ordering. When generating collation based on conditions, default direction and null ordering are used. This leads to wrong planning in case of not default null ordering (additional sort node inserted even if we iterating by index with required collation) and wrong index conditions usage in case of descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16413) Fix .NET documentation for paltform service satistic.
[ https://issues.apache.org/jira/browse/IGNITE-16413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16413: -- Description: Fix .net documentation so that it tells about platform service statistics. > Fix .NET documentation for paltform service satistic. > - > > Key: IGNITE-16413 > URL: https://issues.apache.org/jira/browse/IGNITE-16413 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Fix .net documentation so that it tells about platform service statistics. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16413) Fix .NET documentation for paltform service satistic.
Vladimir Steshin created IGNITE-16413: - Summary: Fix .NET documentation for paltform service satistic. Key: IGNITE-16413 URL: https://issues.apache.org/jira/browse/IGNITE-16413 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16400) Deprecate direct references to local services. Fix service proxy.
[
https://issues.apache.org/jira/browse/IGNITE-16400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-16400:
--
Affects Version/s: 2.11.1
2.12
> Deprecate direct references to local services. Fix service proxy.
> -
>
> Key: IGNITE-16400
> URL: https://issues.apache.org/jira/browse/IGNITE-16400
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.12, 2.11.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> As discussed in the threads related to the main ticket #IGNITE-12464, we
> deprecate references to local services like
> {code:java}
> IgniteServices#service()
> IgniteServices#services()
> {code}
> and fix behavior of the proxies like
> {code:java}
> serviceProxy(String name, Class svcItf, boolean sticky)
> {code}
> so that a proxy is given every time even for local services.
> Reasons in short:
> * Direct references to local services corrupt the service statistics.
> * Direct references to local services bring no real optimization.
> * `serviceProxy()` says 'proxy', '@return Proxy over service'. It should
> return a proxy and do not variate behavior. Especially depending on user-side
> settings
> Also, the documentation of service metrics and limitations or local services
> is going to get improved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16357) Add documentation for DB names format used by API calls
[ https://issues.apache.org/jira/browse/IGNITE-16357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482826#comment-17482826 ] Nikita A. Safonov commented on IGNITE-16357: [~tledkov-gridgain] [~vkulichenko] Please see the PR: https://github.com/apache/ignite-3/pull/596/files > Add documentation for DB names format used by API calls > --- > > Key: IGNITE-16357 > URL: https://issues.apache.org/jira/browse/IGNITE-16357 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Taras Ledkov >Assignee: Nikita A. Safonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > The patch IGNITE-16322 changes behavior of the public API. > Need to document. > API: tuples (java, java client, .net client), IgniteTables, Mapper-s > , -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16351) C++ thin and ODBC: SSL keystore shouldn't be a mandatory parameter
[
https://issues.apache.org/jira/browse/IGNITE-16351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482707#comment-17482707
]
Ignite TC Bot commented on IGNITE-16351:
{panel:title=Branch: [pull/9773/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9773/head] Base: [master] : New Tests
(1050)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
1038|https://ci.ignite.apache.org/viewLog.html?buildId=6387057]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 1027 new tests
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6387058]]
* {color:#013220}IgniteThinClientTest: SslTestSuite: SslConnectionNoCerts -
PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCa - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingKey - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCert - PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6387055]]
* {color:#013220}IgniteThinClientTest: SslTestSuite: SslConnectionNoCerts -
PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCa - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingKey - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCert - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6387056]]
* {color:#013220}IgniteThinClientTest: SslTestSuite: SslConnectionNoCerts -
PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCa - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingKey - PASSED{color}
* {color:#013220}IgniteThinClientTest: SslTestSuite:
SslConnectionErrorNonExistingCert - PASSED{color}
{panel}
[TeamCity *-> Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6387059&buildTypeId=IgniteTests24Java8_RunCpp]
> C++ thin and ODBC: SSL keystore shouldn't be a mandatory parameter
> --
>
> Key: IGNITE-16351
> URL: https://issues.apache.org/jira/browse/IGNITE-16351
> Project: Ignite
> Issue Type: Bug
> Components: odbc, thin client
>Affects Versions: 2.11.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, SSL in C++ thin client and ODBC can't be configured without
> specifying client-side certificates. This shouldn't be the case - SSL can be
> used without any corticates or custom trust stores on the client.
> Need to add a way to do this out of the box.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16402) Fix year check in GridCommandHandler* tests
[
https://issues.apache.org/jira/browse/IGNITE-16402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482662#comment-17482662
]
Ignite TC Bot commented on IGNITE-16402:
{panel:title=Branch: [pull/9770/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6386669]]
{panel}
{panel:title=Branch: [pull/9770/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6386208&buildTypeId=IgniteTests24Java8_RunAll]
> Fix year check in GridCommandHandler* tests
> ---
>
> Key: IGNITE-16402
> URL: https://issues.apache.org/jira/browse/IGNITE-16402
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.13
>
>
> Fix year check in GridCommandHandler* tests:
> * GridCommandHandlerClusterByClassTest.testHelp
> * GridCommandHandlerClusterByClassTest.testCacheHelp
> * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp
> * GridCommandHandlerClusterByClassWithSSLTest.testHelp
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16408) Tests fail when building under specific locales
[ https://issues.apache.org/jira/browse/IGNITE-16408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482635#comment-17482635 ] Roman Puchkovskiy commented on IGNITE-16408: Thank you for the review > Tests fail when building under specific locales > --- > > Key: IGNITE-16408 > URL: https://issues.apache.org/jira/browse/IGNITE-16408 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Roman Puchkovskiy >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > # ConnectionTest#testInvalidNodeAddresses() fails on Linux when Russian > locale is set as the system locale (probably will fail with other non-English > locales) because it expects the error message to be 'Connection refused' > # ExpandableByteBufTest#stringExpandMultipleTimes() fails when Java starts > with a default charset different from UTF-8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16408) Tests fail when building under specific locales
[ https://issues.apache.org/jira/browse/IGNITE-16408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-16408: -- Assignee: Aleksandr Polovtcev (was: Roman Puchkovskiy) > Tests fail when building under specific locales > --- > > Key: IGNITE-16408 > URL: https://issues.apache.org/jira/browse/IGNITE-16408 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Roman Puchkovskiy >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > # ConnectionTest#testInvalidNodeAddresses() fails on Linux when Russian > locale is set as the system locale (probably will fail with other non-English > locales) because it expects the error message to be 'Connection refused' > # ExpandableByteBufTest#stringExpandMultipleTimes() fails when Java starts > with a default charset different from UTF-8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16412) Default cli config contains portRange = 0 as result you can't start 2+ nodes.
Fedor Malchikov created IGNITE-16412:
-
Summary: Default cli config contains portRange = 0 as result you
can't start 2+ nodes.
Key: IGNITE-16412
URL: https://issues.apache.org/jira/browse/IGNITE-16412
Project: Ignite
Issue Type: Bug
Reporter: Fedor Malchikov
Default config:
./ignite config get --type=node
"\{\"clientConnector\":{\"connectTimeout\":5000,\"port\":10800,\"portRange\":100},\"network\":\{\"inbound\":{\"soBacklog\":128,\"soKeepAlive\":true,\"soLinger\":0,\"soReuseAddr\":true,\"tcpNoDelay\":true},\"membership\":\{\"failurePingInterval\":500,\"membershipSyncInterval\":1000,\"scaleCube\":{\"failurePingRequestMembers\":1,\"gossipInterval\":10,\"membershipSuspicionMultiplier\":1}},\"nodeFinder\":\{\"netClusterNodes\":[],\"type\":\"STATIC\"},\"outbound\":\{\"soKeepAlive\":true,\"soLinger\":0,\"tcpNoDelay\":true},\"port\":47500,\"portRange\":0,\"shutdownQuietPeriod\":0,\"shutdownTimeout\":15000},\"node\":\{\"metastorageNodes\":[]},\"rest\":\{\"port\":10300,\"portRange\":100}}"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16411) NPE in org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns
Fedor Malchikov created IGNITE-16411:
-
Summary: NPE in
org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns
Key: IGNITE-16411
URL: https://issues.apache.org/jira/browse/IGNITE-16411
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-alpha3
Reporter: Fedor Malchikov
{code:java}
[INFO ] 2022-01-26 18:39:46,803 [main] com.oltpbenchmark.DBWorkload main -
Finished creating new YCSB database...
Exception in thread "main" java.util.concurrent.CompletionException: class
org.apache.ignite.client.IgniteClientException: null
at
java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
at
java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2044)
at
org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns(JdbcDatabaseMetadata.java:975)
at com.oltpbenchmark.util.SQLUtil.getCatalogDirect(SQLUtil.java:458)
at com.oltpbenchmark.util.SQLUtil.getCatalog(SQLUtil.java:411)
at
com.oltpbenchmark.api.BenchmarkModule.refreshCatalog(BenchmarkModule.java:233)
at com.oltpbenchmark.DBWorkload.main(DBWorkload.java:416)
Caused by: class org.apache.ignite.client.IgniteClientException: null
at
org.apache.ignite.internal.client.TcpClientChannel.convertException(TcpClientChannel.java:241)
at
org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:197)
at
org.apache.ignite.internal.client.TcpClientChannel.serviceAsync(TcpClientChannel.java:143)
at
org.apache.ignite.internal.client.ReliableChannel.handleServiceAsync(ReliableChannel.java:188)
at
org.apache.ignite.internal.client.ReliableChannel.serviceAsync(ReliableChannel.java:144)
at
org.apache.ignite.internal.client.TcpIgniteClient.sendRequestAsync(TcpIgniteClient.java:145)
at
org.apache.ignite.internal.client.query.JdbcClientQueryEventHandler.columnsMetaAsync(JdbcClientQueryEventHandler.java:103)
at
org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns(JdbcDatabaseMetadata.java:974)
... 4 more
Caused by: java.lang.NullPointerException
at io.netty.buffer.ByteBufUtil.utf8MaxBytes(ByteBufUtil.java:948)
at
org.apache.ignite.internal.client.proto.ClientMessagePacker.packString(ClientMessagePacker.java:292)
at
org.apache.ignite.client.proto.query.event.JdbcMetaColumnsRequest.writeBinary(JdbcMetaColumnsRequest.java:89)
at
org.apache.ignite.internal.client.TcpIgniteClient.lambda$sendRequestAsync$1(TcpIgniteClient.java:145)
at
org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:182)
... 10 more {code}
after create table:
{code:sql}
CREATE TABLE usertable (
ycsb_key int PRIMARY KEY,
field1 varchar(100),
field2 varchar(100),
field3 varchar(100),
field4 varchar(100),
field5 varchar(100),
field6 varchar(100),
field7 varchar(100),
field8 varchar(100),
field9 varchar(100),
field10 varchar(100)
);{code}
Reproduced on:
{code:java}
private static AbstractCatalog getCatalogDirect(DatabaseType databaseType,
Connection connection) throws SQLException {
DatabaseMetaData md = connection.getMetaData();
String separator = md.getIdentifierQuoteString();
String catalog = connection.getCatalog();
String schema = connection.getSchema();
Map tables = new HashMap<>();
List excludedColumns = new ArrayList<>();
try (ResultSet table_rs = md.getTables(catalog, schema, null, new
String[]{"TABLE"})) {
while (table_rs.next()) {
String table_type = table_rs.getString("TABLE_TYPE");
if (!table_type.equalsIgnoreCase("TABLE")) {
continue;
}
String table_name = table_rs.getString("TABLE_NAME");
Table catalog_tbl = new Table(table_name, separator);
try (ResultSet col_rs = md.getColumns(catalog, schema, table_name,
null)) {
while (col_rs.next()) {
String col_name = col_rs.getString("COLUMN_NAME");
if (excludedColumns.contains(col_name.toUpperCase())) {
LOG.debug("found excluded column [{}] for in database
type [{}]. Skipping...", col_name, databaseType);
continue;
}
int col_type = col_rs.getInt("DATA_TYPE");
Integer col_size = col_rs.getInt("COLUMN_SIZE");
boolean col_nullable =
col_rs.getString("IS_NULLABLE").equalsIgnoreCase("YES");
Column catalog_col = new Column(col_name, separator,
catalog_tbl, col_type, col_size, col_nullable);
catalog_tbl.addColumn(catalog_col);
}
} {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16408) Tests fail when building under specific locales
[ https://issues.apache.org/jira/browse/IGNITE-16408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482579#comment-17482579 ] Aleksandr Polovtcev commented on IGNITE-16408: -- Looks good, thank you for the contribution > Tests fail when building under specific locales > --- > > Key: IGNITE-16408 > URL: https://issues.apache.org/jira/browse/IGNITE-16408 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > # ConnectionTest#testInvalidNodeAddresses() fails on Linux when Russian > locale is set as the system locale (probably will fail with other non-English > locales) because it expects the error message to be 'Connection refused' > # ExpandableByteBufTest#stringExpandMultipleTimes() fails when Java starts > with a default charset different from UTF-8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14991) Calcite engine. Supports regexp operators
[
https://issues.apache.org/jira/browse/IGNITE-14991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-14991:
Labels: ignite-3 (was: calcite3-required ignite-3)
> Calcite engine. Supports regexp operators
> -
>
> Key: IGNITE-14991
> URL: https://issues.apache.org/jira/browse/IGNITE-14991
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Calcite engine implements {{SqlPosixRegexOperator}}.
> Must be supported by current parser configuration & validator.
> Test:
> {{function/string/regex_filter_pushdown.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.
[ https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482572#comment-17482572 ] Pavel Pereslegin commented on IGNITE-15450: --- [~PetrovMikhail], could you review the proposed changes? > Add special option to run snapshot commands (create/restore) synchronously. > --- > > Key: IGNITE-15450 > URL: https://issues.apache.org/jira/browse/IGNITE-15450 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, ise > Time Spent: 20m > Remaining Estimate: 0h > > The process of restoring a snapshot fails if at least one of the restored > caches already exists. > However, when starting this operation via control.sh, the command returns a > successful startup status, which can be confusing for users. > We can improve this behavior by adding a separate check for existing caches > when starting the restore operation and displaying a user-friendly error > message. > An *alternative* option is to start a snapshot restore operation > synchronously. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15235) Calcite. Unignore or remove tableSpoolBroadcastNotRewindable test
[ https://issues.apache.org/jira/browse/IGNITE-15235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15235: Labels: ignite-3 (was: calcite3-required ignite-3) > Calcite. Unignore or remove tableSpoolBroadcastNotRewindable test > - > > Key: IGNITE-15235 > URL: https://issues.apache.org/jira/browse/IGNITE-15235 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > This test looks synthetic since it changes rewindability of the underlying > table. Need to review this test and fix it or remove if it has no value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15526) Calcite. Incorrect grouping reset during rewind
[ https://issues.apache.org/jira/browse/IGNITE-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15526: Labels: calcite ignite-3 (was: calcite calcite3-required ignite-3) > Calcite. Incorrect grouping reset during rewind > > > Key: IGNITE-15526 > URL: https://issues.apache.org/jira/browse/IGNITE-15526 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: calcite, ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > Currently the aggregate node just clear all groups whereas it should create > new empty group in case of aggregation by empty group set. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.
[ https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482571#comment-17482571 ] Pavel Pereslegin commented on IGNITE-15450: --- [~mpetrov] sorry, my bad, thanks for the feedback! > Add special option to run snapshot commands (create/restore) synchronously. > --- > > Key: IGNITE-15450 > URL: https://issues.apache.org/jira/browse/IGNITE-15450 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, ise > Time Spent: 20m > Remaining Estimate: 0h > > The process of restoring a snapshot fails if at least one of the restored > caches already exists. > However, when starting this operation via control.sh, the command returns a > successful startup status, which can be confusing for users. > We can improve this behavior by adding a separate check for existing caches > when starting the restore operation and displaying a user-friendly error > message. > An *alternative* option is to start a snapshot restore operation > synchronously. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16364) Sql. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. Incorrect grouping reset during rewind.
[ https://issues.apache.org/jira/browse/IGNITE-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16364: Labels: ignite-3 (was: calcite3-required ignite-3) > Sql. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. > Incorrect grouping reset during rewind. > - > > Key: IGNITE-16364 > URL: https://issues.apache.org/jira/browse/IGNITE-16364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 1h 20m > Remaining Estimate: 0h > > Need to merge: > https://issues.apache.org/jira/browse/IGNITE-14991 > https://issues.apache.org/jira/browse/IGNITE-15235 > https://issues.apache.org/jira/browse/IGNITE-15526 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15804) [IGNITE 3] Remove Ignition and IgnitionManager from the public API
[
https://issues.apache.org/jira/browse/IGNITE-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482558#comment-17482558
]
Valentin Kulichenko commented on IGNITE-15804:
--
{{RebalanceExample}} still starts an embedded server node because
{{Ignite#setBaseline}} is not implemented for thin clients.
Looks like we need to complete IGNITE-16410 before we can merge this.
> [IGNITE 3] Remove Ignition and IgnitionManager from the public API
> --
>
> Key: IGNITE-15804
> URL: https://issues.apache.org/jira/browse/IGNITE-15804
> Project: Ignite
> Issue Type: Improvement
>Reporter: Valentin Kulichenko
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> There are currently no plans to support embedded mode in Ignite 3. Thus, we
> should remove {{Ignition}} and {{IgnitionManager}} classes from the public
> API.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16409) Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for appropriate dalays on the input side.
[ https://issues.apache.org/jira/browse/IGNITE-16409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16409: Component/s: sql > Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for > appropriate dalays on the input side. > - > > Key: IGNITE-16409 > URL: https://issues.apache.org/jira/browse/IGNITE-16409 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Priority: Major > > After IGNITE-16364 was merged, IgniteTestStripedThreadPoolExecutor is used > for arbitrary delay tasks execution, the goal of such a functionality is to > test nodes with multiple inputs, for example we can forgot to create some > helpful structures while left input is triggered and right is still empty. > Mostly helpful in joins. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16410) Implement Ignite#setBaseline method in thin client
Valentin Kulichenko created IGNITE-16410:
Summary: Implement Ignite#setBaseline method in thin client
Key: IGNITE-16410
URL: https://issues.apache.org/jira/browse/IGNITE-16410
Project: Ignite
Issue Type: Task
Components: thin client
Affects Versions: 3.0.0-alpha4
Reporter: Valentin Kulichenko
Fix For: 3.0.0-alpha5
Currently, this method is available only on server side - thin client throws
{{{}UnsupportedOperationException{}}}. Because of that, {{RebalanceExample}}
still starts an embedded server node.
Need to implement the method in the thin client and update the example.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16409) Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for appropriate dalays on the input side.
[ https://issues.apache.org/jira/browse/IGNITE-16409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16409: Labels: calcite3-required ignite-3 (was: ) > Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for > appropriate dalays on the input side. > - > > Key: IGNITE-16409 > URL: https://issues.apache.org/jira/browse/IGNITE-16409 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: calcite3-required, ignite-3 > > After IGNITE-16364 was merged, IgniteTestStripedThreadPoolExecutor is used > for arbitrary delay tasks execution, the goal of such a functionality is to > test nodes with multiple inputs, for example we can forgot to create some > helpful structures while left input is triggered and right is still empty. > Mostly helpful in joins. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.
[ https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482556#comment-17482556 ] Michal Petrov commented on IGNITE-15450: [~xtern], I think you've got the wrong person. > Add special option to run snapshot commands (create/restore) synchronously. > --- > > Key: IGNITE-15450 > URL: https://issues.apache.org/jira/browse/IGNITE-15450 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, ise > Time Spent: 20m > Remaining Estimate: 0h > > The process of restoring a snapshot fails if at least one of the restored > caches already exists. > However, when starting this operation via control.sh, the command returns a > successful startup status, which can be confusing for users. > We can improve this behavior by adding a separate check for existing caches > when starting the restore operation and displaying a user-friendly error > message. > An *alternative* option is to start a snapshot restore operation > synchronously. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16409) Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for appropriate dalays on the input side.
Evgeny Stanilovsky created IGNITE-16409: --- Summary: Need to replace temporary stub: IgniteTestStripedThreadPoolExecutor for appropriate dalays on the input side. Key: IGNITE-16409 URL: https://issues.apache.org/jira/browse/IGNITE-16409 Project: Ignite Issue Type: Improvement Reporter: Evgeny Stanilovsky After IGNITE-16364 was merged, IgniteTestStripedThreadPoolExecutor is used for arbitrary delay tasks execution, the goal of such a functionality is to test nodes with multiple inputs, for example we can forgot to create some helpful structures while left input is triggered and right is still empty. Mostly helpful in joins. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15804) [IGNITE 3] Remove Ignition and IgnitionManager from the public API
[
https://issues.apache.org/jira/browse/IGNITE-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-15804:
Assignee: Vyacheslav Koptilin (was: Sergey Uttsel)
> [IGNITE 3] Remove Ignition and IgnitionManager from the public API
> --
>
> Key: IGNITE-15804
> URL: https://issues.apache.org/jira/browse/IGNITE-15804
> Project: Ignite
> Issue Type: Improvement
>Reporter: Valentin Kulichenko
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> There are currently no plans to support embedded mode in Ignite 3. Thus, we
> should remove {{Ignition}} and {{IgnitionManager}} classes from the public
> API.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15945) Class inheritance and effectively final fields
[ https://issues.apache.org/jira/browse/IGNITE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-15945: -- Assignee: Roman Puchkovskiy > Class inheritance and effectively final fields > -- > > Key: IGNITE-15945 > URL: https://issues.apache.org/jira/browse/IGNITE-15945 > Project: Ignite > Issue Type: Task >Reporter: Semyon Danilov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 40m > Remaining Estimate: 0h > > Support inheritance of user objects and polymorphic fields. > During the class instance (de)serialization, the (de)serializer traverses the > fields from the descriptor and writes: > * Field's value class descriptor ID and field data if the declared field's > class is non-final. This allows supporting polymorphic fields. > * Field data without field value class descriptor if declared field's class > is final. In this case, the actual field's value object is guaranteed to be > equal to the declared field class. > See > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16235) Races between query execution and table creation
[ https://issues.apache.org/jira/browse/IGNITE-16235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482537#comment-17482537 ] Evgeny Stanilovsky commented on IGNITE-16235: - [~korlov] fixed. > Races between query execution and table creation > > > Key: IGNITE-16235 > URL: https://issues.apache.org/jira/browse/IGNITE-16235 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > While the IGNITE-16090 fixes the issue, the provided patch lacks of proper > integration test that would verify the fix automatically. So we need to add > the test with follow scenario: > - cluster of 2 or more nodes is started > - create a table and immediately run a query upon that table > To reveal the original issue, we need to delay ditributed event of a table > creation on the node somehow in order to make the query be executed before > the table structures were created. > I believe this is not the only such a test, so we need a general approach to > write tests to verify the cluster behaviour in a concurrent environment. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-15161) Implement component's stop
[ https://issues.apache.org/jira/browse/IGNITE-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-15161. -- Fix Version/s: 3.0.0-alpha5 Resolution: Fixed > Implement component's stop > -- > > Key: IGNITE-15161 > URL: https://issues.apache.org/jira/browse/IGNITE-15161 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Original Estimate: 120h > Time Spent: 10m > Remaining Estimate: 119h 50m > > During the work on https://issues.apache.org/jira/browse/IGNITE-15278, the > general flow of the components start and stop was introduced. > It is needed to implement a stop mechanism for every component. > The main points that should be considered during the implementation of > component's stop: > * All threads should be stopped properly > * All Executors should be shutdown > * All public methods should be guarded by read lock, stop should be done > using write lock. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-15613) jraft module is excluded from javadoc and checkstyle checking
[ https://issues.apache.org/jira/browse/IGNITE-15613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-15613. -- Resolution: Won't Fix I don't think that this task is absolutely required. > jraft module is excluded from javadoc and checkstyle checking > -- > > Key: IGNITE-15613 > URL: https://issues.apache.org/jira/browse/IGNITE-15613 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3, tech-debt > > After the integration of jraft module to ignite, we decided to exclude > javadoc and checkstyle checking for raft module, as far as jraft's checkstyle > differs from ignite's. Also, jraft doesn't have enough javadocs. > It's needed to include raft module to javadoc and checkstyle checking. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16197) Excessive GC pressure on sending messages in network module
[ https://issues.apache.org/jira/browse/IGNITE-16197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov resolved IGNITE-16197. -- Fix Version/s: (was: 3.0) Resolution: Won't Fix This situation was used by a implementation details of ScaleCube method used in network module. This usage was removed in other ticket, no need to fix this one. > Excessive GC pressure on sending messages in network module > --- > > Key: IGNITE-16197 > URL: https://issues.apache.org/jira/browse/IGNITE-16197 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 3.0.0-alpha3 >Reporter: Sergey Chugunov >Priority: Major > Labels: ignite-3 > > Messaging service in networking module performs a check on whether the node > is shutting down on sending each message. > This check is performed via ScaleCube ClusterImpl#isShutdown method call > which creates excessive garbage. > We should eliminate usage of this method and listen to shutdown event instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15632) Investigate jraft's BallotBox optimisation in case of removing peer
[
https://issues.apache.org/jira/browse/IGNITE-15632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15632:
-
Labels: ignite-3 (was: ignite-3 tech-debt)
> Investigate jraft's BallotBox optimisation in case of removing peer
> ---
>
> Key: IGNITE-15632
> URL: https://issues.apache.org/jira/browse/IGNITE-15632
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> {{org.apache.ignite.raft.jraft.core.BallotBox#commitAt}} method contains
> comment from jraft developers about optimization which commits uncommitted
> logs in case of decreasing of quorum. This optimization is not proven, needs
> to be investigated.
> Comment:
> {noformat}
> // When removing a peer off the raft group which contains even
> number of
> // peers, the quorum would decrease by 1, e.g. 3 of 4 changes to
> 2 of 3. In
> // this case, the log after removal may be committed before some
> previous
> // logs, since we use the new configuration to deal the quorum of
> the
> // removal request, we think it's safe to commit all the
> uncommitted
> // previous logs, which is not well proved right now
> {noformat}
> Ticket was created after the decomposition of
> https://issues.apache.org/jira/browse/IGNITE-14832
> See todo in {{org.apache.ignite.raft.jraft.core.BallotBox#commitAt}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-15617) TableManager API improvements
[ https://issues.apache.org/jira/browse/IGNITE-15617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-15617. -- Resolution: Fixed > TableManager API improvements > - > > Key: IGNITE-15617 > URL: https://issues.apache.org/jira/browse/IGNITE-15617 > Project: Ignite > Issue Type: Epic >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3, tech-debt > > Currently, the TableManager's API is an API whose sole purpose is to show how > TableManager works with raft, which was the runner of the alpha2 release. > There is room for improvements for TableManager API according to components, > that were supposed to use the API: public ignite api, sql components (ddl), > client nodes. > For example, It should be considered to separate public and internal API, > public exceptions should be meaningful, etc -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-15726) Research non-sql production-proven table management api options.
[
https://issues.apache.org/jira/browse/IGNITE-15726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-15726.
--
Resolution: Won't Fix
Looks like createTable and similar methods should be removed from public API
> Research non-sql production-proven table management api options.
>
>
> Key: IGNITE-15726
> URL: https://issues.apache.org/jira/browse/IGNITE-15726
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> Let's check how other vendors solve the issue of non-sql api to manager
> tables or table like structures.
> h3. Problem
> Currently there are two variants of internal table api:
> * The one that uses closure as a parameter, e.g. _Table createTable(String
> name, Consumer tableInitChange);_
> * Syntactic sugar over closures presented in the form of a builder
> {code:java}
> TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
> "tbl1").columns(
> SchemaBuilders.column("key",
> ColumnType.INT64).asNonNull().build(),
> SchemaBuilders.column("val",
> ColumnType.INT32).asNullable().build()
> ).withPrimaryKey("key").build();
> clusterNodes.get(0).tables().createTable(schTbl1.canonicalName(),
> tblCh ->
> SchemaConfigurationConverter.convert(schTbl1, tblCh)
> .changeReplicas(1)
> .changePartitions(10)
> );
> {code}
> It's not possible to use first option from within thin clients cause it's not
> possible to transfer closure over network.
> Second one is better however it doesn't support rename and some other alter
> operations.
> It worth to mention that there's and
> [option|https://issues.apache.org/jira/browse/IGNITE-15557] of pojo based
> configuration api that is similar to builders and has similar disadvantages.
> Taking into consideration that api mentioned above partially duplicates ddl
> for tables it makes sense to do a research checking whether other vendors
> provide such kind of non-ddl table management api.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-14987) Cluster bootstrapping and lifecycle research
[ https://issues.apache.org/jira/browse/IGNITE-14987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov resolved IGNITE-14987. -- Resolution: Duplicate Both topics (bootstrapping and lifecycle) were studied and clarified in other tickets. > Cluster bootstrapping and lifecycle research > > > Key: IGNITE-14987 > URL: https://issues.apache.org/jira/browse/IGNITE-14987 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Priority: Major > Labels: ignite-3 > > In order to start a cluster with Raft-based metastorage we need to define a > bootstrapping process and stages cluster should go through. > This involves defining lifecycle of individual components within a node, node > itself and cluster in general. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-14414) Cluster initialization flow
[ https://issues.apache.org/jira/browse/IGNITE-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-14414. -- Resolution: Won't Fix This ticket should be revised in the context of https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186876642 > Cluster initialization flow > --- > > Key: IGNITE-14414 > URL: https://issues.apache.org/jira/browse/IGNITE-14414 > Project: Ignite > Issue Type: New Feature >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > For a cluster to become operational, the metastorage instance must be > initialized first. The initialization command chooses a set of nodes > (normally, 3 - 5 nodes) to host the distributed metastorage Raft group. When > a node receives the initialization command, it either creates a bootstrapped > Raft instance with the given members (if this is a metastorage group node), > or writes the metastorage group member IDs to the vault as a private > system-level property. > After the metastorage is initialized, components start to receive and process > watch events, updating the local state according to the changes received from > the watch. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-14415) Define protocol of creating distributed metastorage group
[ https://issues.apache.org/jira/browse/IGNITE-14415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-14415. -- Resolution: Won't Fix This ticket should be revised in the context of https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186876642 > Define protocol of creating distributed metastorage group > - > > Key: IGNITE-14415 > URL: https://issues.apache.org/jira/browse/IGNITE-14415 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Kirill Gusakov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-14416) Cluster initialization via ignite-ctl tool
[ https://issues.apache.org/jira/browse/IGNITE-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-14416. -- Resolution: Won't Fix This ticket should be revised in the context of https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186876642 > Cluster initialization via ignite-ctl tool > -- > > Key: IGNITE-14416 > URL: https://issues.apache.org/jira/browse/IGNITE-14416 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16408) Tests fail when building under specific locales
[ https://issues.apache.org/jira/browse/IGNITE-16408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-16408: --- Summary: Tests fail when building under specific locales (was: Tests fail when building on specific locales) > Tests fail when building under specific locales > --- > > Key: IGNITE-16408 > URL: https://issues.apache.org/jira/browse/IGNITE-16408 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > # ConnectionTest#testInvalidNodeAddresses() fails on Linux when Russian > locale is set as the system locale (probably will fail with other non-English > locales) because it expects the error message to be 'Connection refused' > # ExpandableByteBufTest#stringExpandMultipleTimes() fails when Java starts > with a default charset different from UTF-8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16322) Database object names case inconsisten between SQL and KV API
[
https://issues.apache.org/jira/browse/IGNITE-16322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16322:
--
Description:
Current naming of the database object is not clear for everyone.
*Current behavior*
{{CREATE TABLE mytable(id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> fails with table not found
{{ignite.tables().table("PUBLIC.MYTABLE ");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable(ID,
VAL)
{{ignite.tables().table("PUBLIC.MyTable");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{tbl.get().value("id")}} -> fails with error: column not found
{{tbl.get().value("ID")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns Id column's value
*Proposed Fixes*
*1. Use case insensitive collation to compare and lookup database object*
e.g.
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> fails with error:
PUBLIC.MYTABLE already exists,
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> fails with error:
duplicate column name: ID
{{tbl.get().value("id")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns ID column's value
*2. Case sensitive collation for DB object names and parse string argument of
the name passed through API*
Use quotation for string values by API
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable
{{ignite.tables().table("public.\"MyTable\"");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{Tupel tuple = ...}}
{{tuple.value("id")}} -> returns ID column's value
{{tuple.value("Id")}} -> returns ID column's value
{{tuple.value("\"Id\"")}} -> returns Id column's value
was:
Current naming of the database object is not clear for everyone.
*Current behavior*
{{CREATE TABLE mytable(id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> fails with table not found
{{ignite.tables().table("PUBLIC.MYTABLE ");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable(ID,
VAL)
{{ignite.tables().table("PUBLIC.MyTable");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{tbl.get().value("id")}} -> fails with error: column not found
{{tbl.get().value("ID")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns Id column's value
*Proposed Fixes*
*1. Use case insensitive collation to compare and lookup database object*
e.g.
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> fails with error:
PUBLIC.MYTABLE already exists,
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> fails with error:
duplicate column name: ID
{{tbl.get().value("id")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns ID column's value
*2. Case sensitive collation for DB object names and parse string argument of
the name passed through API*
Use quotation for string values by API
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable
{{ignite.tables().table("public.\"MyTable\"");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{tbl.get().value("id")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns ID column's value
{{tbl.get().value("\"Id\"")}} -> returns Id column's value
> Database object names case inconsisten between SQL and KV API
> -
>
> Key: IGNITE-16322
> URL: https://issues.apache.org/jira/browse/IGNITE-16322
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 1h 10m
> Remaining Estimate
[jira] [Updated] (IGNITE-16322) Database object names case inconsisten between SQL and KV API
[
https://issues.apache.org/jira/browse/IGNITE-16322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16322:
--
Description:
Current naming of the database object is not clear for everyone.
*Current behavior*
{{CREATE TABLE mytable(id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> fails with table not found
{{ignite.tables().table("PUBLIC.MYTABLE ");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable(ID,
VAL)
{{ignite.tables().table("PUBLIC.MyTable");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{tbl.get().value("id")}} -> fails with error: column not found
{{tbl.get().value("ID")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns Id column's value
*Proposed Fixes*
*1. Use case insensitive collation to compare and lookup database object*
e.g.
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> fails with error:
PUBLIC.MYTABLE already exists,
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> fails with error:
duplicate column name: ID
{{tbl.get().value("id")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns ID column's value
*2. Case sensitive collation for DB object names and parse string argument of
the name passed through API*
Use quotation for string values by API
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable
{{ignite.tables().table("public.\"MyTable\"");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{Tuple tuple = ...}}
{{tuple.value("id")}} -> returns ID column's value
{{tuple.value("Id")}} -> returns ID column's value
{{tuple.value("\"Id\"")}} -> returns Id column's value
was:
Current naming of the database object is not clear for everyone.
*Current behavior*
{{CREATE TABLE mytable(id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> fails with table not found
{{ignite.tables().table("PUBLIC.MYTABLE ");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable(ID,
VAL)
{{ignite.tables().table("PUBLIC.MyTable");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{tbl.get().value("id")}} -> fails with error: column not found
{{tbl.get().value("ID")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns Id column's value
*Proposed Fixes*
*1. Use case insensitive collation to compare and lookup database object*
e.g.
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE (ID, VAL)
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> fails with error:
PUBLIC.MYTABLE already exists,
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> fails with error:
duplicate column name: ID
{{tbl.get().value("id")}} -> returns ID column's value
{{tbl.get().value("Id")}} -> returns ID column's value
*2. Case sensitive collation for DB object names and parse string argument of
the name passed through API*
Use quotation for string values by API
{{CREATE TABLE MyTable (id INT, val INT)}}; -> creates PUBLIC.MYTABLE
{{ignite.tables().table("public.mytable");}} -> returns PUBLIC.MYTABLE
{{CREATE TABLE \"MyTable\" (id INT, val INT)}}; -> creates PUBLIC.MyTable
{{ignite.tables().table("public.\"MyTable\"");}} -> returns PUBLIC.MyTable
Tuple / column behavior:
{{CREATE TABLE MyTable (id INT, \"Id\" INT, val INT)}}; -> creates
PUBLIC.MYTABLE (ID, Id, VAL)
{{Tupel tuple = ...}}
{{tuple.value("id")}} -> returns ID column's value
{{tuple.value("Id")}} -> returns ID column's value
{{tuple.value("\"Id\"")}} -> returns Id column's value
> Database object names case inconsisten between SQL and KV API
> -
>
> Key: IGNITE-16322
> URL: https://issues.apache.org/jira/browse/IGNITE-16322
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 1h 10m
> Remainin
[jira] [Created] (IGNITE-16408) Tests fail when building on specific locales
Roman Puchkovskiy created IGNITE-16408: -- Summary: Tests fail when building on specific locales Key: IGNITE-16408 URL: https://issues.apache.org/jira/browse/IGNITE-16408 Project: Ignite Issue Type: Bug Components: general Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha5 # ConnectionTest#testInvalidNodeAddresses() fails on Linux when Russian locale is set as the system locale (probably will fail with other non-English locales) because it expects the error message to be 'Connection refused' # ExpandableByteBufTest#stringExpandMultipleTimes() fails when Java starts with a default charset different from UTF-8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16407) In-depth CC related Cockroach research
Alexander Lapin created IGNITE-16407: Summary: In-depth CC related Cockroach research Key: IGNITE-16407 URL: https://issues.apache.org/jira/browse/IGNITE-16407 Project: Ignite Issue Type: Task Reporter: Alexander Lapin Let's read, understand and discuss following papers: [https://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-transactions/] [https://www.cockroachlabs.com/blog/transaction-pipelining/] https://www.cockroachlabs.com/blog/parallel-commits/ https://dl.acm.org/doi/pdf/10.1145/3318464.3386134 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16406:
-
Priority: Blocker (was: Major)
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16406:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-16284) In-depth CC related spanner research
[ https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-16284. -- Resolution: Fixed > In-depth CC related spanner research > > > Key: IGNITE-16284 > URL: https://issues.apache.org/jira/browse/IGNITE-16284 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Attachments: Spanner (2).png, Spanner (4).png > > > Let's read, understand and discuss the following spanner specific docs > [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] > [https://blog.the-pans.com/notes-on-the-spanner/] > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > Let's read, understand and discuss the following spanner specific docs > [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] > [https://blog.the-pans.com/notes-on-the-spanner/] > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > h2. Research results > Spanner is Google’s scalable, multi-version, globally-distributed, and > synchronously-replicated database. From the transaction's point of view > Spanner is a system that guarantees external consistency and provides > lock-free read-only and pessimistic read-write transactions. It worth > mentioning that Spanner widely uses TrueTime with corresponding commit Wait > logic. Bellow there’s a detail explanation of how read-write and read-only > transactions are work in Spanner. > h4. Read-Write Transactions > For transactions that involve multiple Paxos groups, Spanner uses the > two-phase commit protocol with long-held locks to guarantee that read-write > transactions provide external consistency. > The client buffers the write operations that occur in a transaction until it > is ready to commit. At commit time, it chooses a leader of one of the Paxos > groups to act as the transaction coordinator and sends a prepare message with > the buffered writes and the identity of the coordinator to the leaders of the > other participant groups. Each participant leader then acquires writes locks > and performs the specified operations before responding to the coordinator > with the status of its mini-transaction. > The client also issues reads within read-write transactions to the leader > replica of the relevant group, which acquires read locks and reads the most > recent data. One of the other limitations of two-phase commit highlighted in > the previous lecture is its proneness to deadlocks. Spanner uses the > wound-wait locking rule to avoid deadlocks when reading data. > > !Spanner (2).png|width=666,height=611! > h4. Read-Only Transactions > Spanner makes two optimizations to achieve greater performance in read-only > transactions: > # It does not hold locks or use the two-phase commit protocol to serve > requests. > # It allows reads from replicas. > In order to guarantee external consistency through snapshot isolation Spanner > keeps multiple versions of an object—each version labelled with a timestamp > representing what transaction produced it. Snapshot isolation enforces that a > read-only transaction will only see the versions of a record that have a > timestamp less than its assigned transaction timestamp i.e. a snapshot of > what the record was before the transaction started. To prevent reading stale > data from non-majority replicas, each replica maintains a _safe time_ > property, which is the maximum timestamp at which it is up to date. Paxos > leaders send writes to followers in timestamp order and the safe time > represents the most recent timestamp a replica has seen. > > !Spanner (4).png|width=676,height=520! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16405) NoClassDefFound on invokeAsync when using BinaryObjects.
[ https://issues.apache.org/jira/browse/IGNITE-16405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-16405: -- Summary: NoClassDefFound on invokeAsync when using BinaryObjects. (was: NoClassDefFound on entry processor invokeAsync with using BinaryObjects.) > NoClassDefFound on invokeAsync when using BinaryObjects. > > > Key: IGNITE-16405 > URL: https://issues.apache.org/jira/browse/IGNITE-16405 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Attachments: stacktrace.txt > > > Tx cache async operation may fail with an error on retry in case when the > binary projection is used. > This happens due to the lost CacheOperationContext, which holds 'keepBinary' > flag, on retry and leads to object deserialization when TX is trying to > enlist en entry. > PFA stacktrace. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16284) In-depth CC related spanner research
[ https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16284: - Description: Let's read, understand and discuss the following spanner specific docs [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] [https://blog.the-pans.com/notes-on-the-spanner/] [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] Let's read, understand and discuss the following spanner specific docs [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] [https://blog.the-pans.com/notes-on-the-spanner/] [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] h2. Research results Spanner is Google’s scalable, multi-version, globally-distributed, and synchronously-replicated database. From the transaction's point of view Spanner is a system that guarantees external consistency and provides lock-free read-only and pessimistic read-write transactions. It worth mentioning that Spanner widely uses TrueTime with corresponding commit Wait logic. Bellow there’s a detail explanation of how read-write and read-only transactions are work in Spanner. h4. Read-Write Transactions For transactions that involve multiple Paxos groups, Spanner uses the two-phase commit protocol with long-held locks to guarantee that read-write transactions provide external consistency. The client buffers the write operations that occur in a transaction until it is ready to commit. At commit time, it chooses a leader of one of the Paxos groups to act as the transaction coordinator and sends a prepare message with the buffered writes and the identity of the coordinator to the leaders of the other participant groups. Each participant leader then acquires writes locks and performs the specified operations before responding to the coordinator with the status of its mini-transaction. The client also issues reads within read-write transactions to the leader replica of the relevant group, which acquires read locks and reads the most recent data. One of the other limitations of two-phase commit highlighted in the previous lecture is its proneness to deadlocks. Spanner uses the wound-wait locking rule to avoid deadlocks when reading data. !Spanner (2).png|width=666,height=611! h4. Read-Only Transactions Spanner makes two optimizations to achieve greater performance in read-only transactions: # It does not hold locks or use the two-phase commit protocol to serve requests. # It allows reads from replicas. In order to guarantee external consistency through snapshot isolation Spanner keeps multiple versions of an object—each version labelled with a timestamp representing what transaction produced it. Snapshot isolation enforces that a read-only transaction will only see the versions of a record that have a timestamp less than its assigned transaction timestamp i.e. a snapshot of what the record was before the transaction started. To prevent reading stale data from non-majority replicas, each replica maintains a _safe time_ property, which is the maximum timestamp at which it is up to date. Paxos leaders send writes to followers in timestamp order and the safe time represents the most recent timestamp a replica has seen. !Spanner (4).png|width=676,height=520! was: Let's read, understand and discuss the following spanner specific docs https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf https://blog.the-pans.com/notes-on-the-spanner/ [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > In-depth CC related spanner research > > > Key: IGNITE-16284 > URL: https://issues.apache.org/jira/browse/IGNITE-16284 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Attachments: Spanner (2).png, Spanner (4).png > > > Let's read, understand and discuss the following spanner specific docs > [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] > [https://blog.the-pans.com/notes-on-the-spanner/] > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > Let's read, understand and discuss the following spanner specific docs > [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf] > [https://blog.the-pans.com/notes-on-the-spanner/] > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > h2. Research results > Spanner is Google’s scalable, multi-version, globally-distributed, an
[jira] [Updated] (IGNITE-16284) In-depth CC related spanner research
[ https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16284: - Attachment: Spanner (4).png > In-depth CC related spanner research > > > Key: IGNITE-16284 > URL: https://issues.apache.org/jira/browse/IGNITE-16284 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Attachments: Spanner (2).png, Spanner (4).png > > > Let's read, understand and discuss the following spanner specific docs > https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf > https://blog.the-pans.com/notes-on-the-spanner/ > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16284) In-depth CC related spanner research
[ https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16284: - Attachment: Spanner (2).png > In-depth CC related spanner research > > > Key: IGNITE-16284 > URL: https://issues.apache.org/jira/browse/IGNITE-16284 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Attachments: Spanner (2).png > > > Let's read, understand and discuss the following spanner specific docs > https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf > https://blog.the-pans.com/notes-on-the-spanner/ > [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16406:
-
Labels: ignite-3 (was: )
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16394) Provide enum of released versions to compatibility tests
[ https://issues.apache.org/jira/browse/IGNITE-16394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482497#comment-17482497 ] Amelchev Nikita commented on IGNITE-16394: -- Merged into the master. Fixed the wiki release page. [~PetrovMikhail], [~xtern], thank you for the review. > Provide enum of released versions to compatibility tests > > > Key: IGNITE-16394 > URL: https://issues.apache.org/jira/browse/IGNITE-16394 > Project: Ignite > Issue Type: Improvement >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Compatibility tests require updating each test class when a new version is > released. > Seems we can have a single enum of released versions and reuse it in tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16406:
-
Description:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can slow down a bit message handling, for example by adding
this code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing
was:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can a bit slow down message handling, for example add this
code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16406) SQL select operation could return incomplete data
Mirza Aliev created IGNITE-16406:
Summary: SQL select operation could return incomplete data
Key: IGNITE-16406
URL: https://issues.apache.org/jira/browse/IGNITE-16406
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Assignee: Mirza Aliev
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can a bit slow down message handling, for example add this
code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16394) Provide enum of released versions to compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-16394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482495#comment-17482495
]
Ignite TC Bot commented on IGNITE-16394:
{panel:title=Branch: [pull/9765/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6385598]]
{panel}
{panel:title=Branch: [pull/9765/head] Base: [master] : New Tests
(25)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Compatibility){color} [[tests
25|https://ci.ignite.apache.org/viewLog.html?buildId=6385695]]
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.8.1]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.9.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.9.1]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.10.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.6.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.7.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.7.6]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.8.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.2.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.3.0]
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData[version=2.4.0]
- PASSED{color}
... and 14 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6385693&buildTypeId=IgniteTests24Java8_RunAll]
> Provide enum of released versions to compatibility tests
>
>
> Key: IGNITE-16394
> URL: https://issues.apache.org/jira/browse/IGNITE-16394
> Project: Ignite
> Issue Type: Improvement
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Compatibility tests require updating each test class when a new version is
> released.
> Seems we can have a single enum of released versions and reuse it in tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16405) NoClassDefFound on entry processor invokeAsync with using BinaryObjects.
[ https://issues.apache.org/jira/browse/IGNITE-16405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-16405: - Assignee: Andrey Mashenkov > NoClassDefFound on entry processor invokeAsync with using BinaryObjects. > > > Key: IGNITE-16405 > URL: https://issues.apache.org/jira/browse/IGNITE-16405 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Attachments: stacktrace.txt > > > Tx cache async operation may fail with an error on retry in case when the > binary projection is used. > This happens due to the lost CacheOperationContext, which holds 'keepBinary' > flag, on retry and leads to object deserialization when TX is trying to > enlist en entry. > PFA stacktrace. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16405) NoClassDefFound on entry processor invokeAsync with using BinaryObjects.
Andrey Mashenkov created IGNITE-16405: - Summary: NoClassDefFound on entry processor invokeAsync with using BinaryObjects. Key: IGNITE-16405 URL: https://issues.apache.org/jira/browse/IGNITE-16405 Project: Ignite Issue Type: Bug Components: cache Reporter: Andrey Mashenkov Attachments: stacktrace.txt Tx cache async operation may fail with an error on retry in case when the binary projection is used. This happens due to the lost CacheOperationContext, which holds 'keepBinary' flag, on retry and leads to object deserialization when TX is trying to enlist en entry. PFA stacktrace. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16404) Enable Unsafe for netty
Semyon Danilov created IGNITE-16404: --- Summary: Enable Unsafe for netty Key: IGNITE-16404 URL: https://issues.apache.org/jira/browse/IGNITE-16404 Project: Ignite Issue Type: Task Components: networking Reporter: Semyon Danilov Assignee: Semyon Danilov Adding -Dio.netty.tryReflectionSetAccessible=true can potentially speed up networking due to netty creating ByteBufs from DirectByteBuffer's without cleaners. Note that --add-opens java.base/jdk.internal.misc=ALL-UNNAMED should be added -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16357) Add documentation for DB names format used by API calls
[ https://issues.apache.org/jira/browse/IGNITE-16357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita A. Safonov reassigned IGNITE-16357: -- Assignee: Nikita A. Safonov > Add documentation for DB names format used by API calls > --- > > Key: IGNITE-16357 > URL: https://issues.apache.org/jira/browse/IGNITE-16357 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Taras Ledkov >Assignee: Nikita A. Safonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > The patch IGNITE-16322 changes behavior of the public API. > Need to document. > API: tuples (java, java client, .net client), IgniteTables, Mapper-s > , -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16403) [Ignite Website] Recognition service widget fix
Kseniya Romanova created IGNITE-16403: - Summary: [Ignite Website] Recognition service widget fix Key: IGNITE-16403 URL: https://issues.apache.org/jira/browse/IGNITE-16403 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova Assignee: Erlan Aytpaev Please fix the recognition service on the Community Page [https://ignite.apache.org/our-community.html#contributing] at the moment we have just an empty frame in the *Project Awareness* *Top Contributors.* Iframe src: TOP 10 for previous quarter [https://recognition.gridgain.com/leaderboard-frame?limit=10&interval=prev-quarter&product=ignite] parameter: limit - leaderboard size interval - alltime, this-quarter, prev-quarter, this-year, prev-year, widget width = iframe width (100% or fixed size) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16366) Add causality tokens for notifications
[
https://issues.apache.org/jira/browse/IGNITE-16366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16366:
-
Epic Link: IGNITE-16362
> Add causality tokens for notifications
> --
>
> Key: IGNITE-16366
> URL: https://issues.apache.org/jira/browse/IGNITE-16366
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Cluster-wide events, such as, for example, configuration changes or
> Metastorage updates, trigger notifications that are propagated to the nodes
> and therefore, to components. Every event can trigger several notifications.
> Every notification has a causality token. Notifications triggered by the same
> event have the same causality token.
> {{Tokens should be added to
> org.apache.ignite.internal.manager.EventParameters}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16363) Provide a guarantee of completeness of pre-recovery actions
[ https://issues.apache.org/jira/browse/IGNITE-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16363: - Epic Link: IGNITE-16362 > Provide a guarantee of completeness of pre-recovery actions > --- > > Key: IGNITE-16363 > URL: https://issues.apache.org/jira/browse/IGNITE-16363 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > We need to be sure that recovery should perform on the node after it has > joined physical topology and has been validated via node join protocol. > Necessary prerequisites for the recovery start are following: > * the node has retrieved the information and metastorage group from Vault; > * the node has received a join response in case of non-standalone mode, > meaning that the node is validated and is allowed to join the cluster. This > step can be mocked for now; > * all components have started and subscribed on configuration updates and > events. After this, notifications should be allowed and the recovery actually > starts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16365) Implement a logic of recovery finishing
[ https://issues.apache.org/jira/browse/IGNITE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16365: - Epic Link: IGNITE-16362 > Implement a logic of recovery finishing > --- > > Key: IGNITE-16365 > URL: https://issues.apache.org/jira/browse/IGNITE-16365 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > The key point of local state recovery is catching of latest revision applied > in metastorage to apply it locally. In case of standalone mode the node > should finish recovery after restoring components' state from vault, > otherwise it should retrieve updates from metastorage. Notifications from > metastorage should be allowed on recovery stage after all components have > started, and recovery should continue until the node has reached minimal > acceptable difference between itself and the cluster. > Need to implement: > * methods for getting the minimal available revision in Metastorage and the > last applied one; > * some recovery processor class intended to do the logic related to catching > last metastorage revision, and responsile for firing FinishedRecovery message > to cluster management group. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16367) Notification about storage revision update
[ https://issues.apache.org/jira/browse/IGNITE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16367: - Epic Link: IGNITE-16362 > Notification about storage revision update > -- > > Key: IGNITE-16367 > URL: https://issues.apache.org/jira/browse/IGNITE-16367 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Every event should produce a storage revision update notification along with > all the rest required notifications. This notification should have the same > causality token, It should be guaranteed that this notification will be the > last of all notifications triggered by one certain event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16371) Improvements of start() methods of Ignite components for local recovery
[ https://issues.apache.org/jira/browse/IGNITE-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16371: - Epic Link: IGNITE-16362 > Improvements of start() methods of Ignite components for local recovery > --- > > Key: IGNITE-16371 > URL: https://issues.apache.org/jira/browse/IGNITE-16371 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > These methods should take into account that the listeners should be started > on components' start, and notifications for these listeners are allowed after > the start of all components has been completed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16372) Make a research about possibility of performing a rebalance on recovery
[ https://issues.apache.org/jira/browse/IGNITE-16372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16372: - Epic Link: IGNITE-16362 > Make a research about possibility of performing a rebalance on recovery > --- > > Key: IGNITE-16372 > URL: https://issues.apache.org/jira/browse/IGNITE-16372 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > A possible optimization is to perform rebalance on node recovery, to make > sure that in the moment when the node joins logical topology it is ready to > serve user load. Research is needed to check whether it's possible to > distinguish the rebalance and user load to allow the former on recovery > without allowing the latter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16369) Any() mode for the component listeners
[ https://issues.apache.org/jira/browse/IGNITE-16369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16369: - Epic Link: IGNITE-16362 > Any() mode for the component listeners > -- > > Key: IGNITE-16369 > URL: https://issues.apache.org/jira/browse/IGNITE-16369 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > The component listeners should have ability to be configured in a way to > handle properly notifications for any component. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16368) Implement a futures for causality tokens
[ https://issues.apache.org/jira/browse/IGNITE-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16368: - Epic Link: IGNITE-16362 > Implement a futures for causality tokens > > > Key: IGNITE-16368 > URL: https://issues.apache.org/jira/browse/IGNITE-16368 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > One can create a future for some component with some causality token. This > future completes when this component has handled all notifications having the > given causality token. More formally, it completes when the component handles > notification about storage revision update having the given causality token. > When a component listener handles a notification, it must execute the code > that relies on the state of the depended component, after completion of the > future, created for this component with a certain causality token received > within the notification. This guarantees that notifications will be handled > by component listeners in a proper order. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16364) Sql. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. Incorrect grouping reset during rewind.
[ https://issues.apache.org/jira/browse/IGNITE-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482469#comment-17482469 ] Konstantin Orlov commented on IGNITE-16364: --- LGTM > Sql. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. > Incorrect grouping reset during rewind. > - > > Key: IGNITE-16364 > URL: https://issues.apache.org/jira/browse/IGNITE-16364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite3-required, ignite-3 > Time Spent: 1h 10m > Remaining Estimate: 0h > > Need to merge: > https://issues.apache.org/jira/browse/IGNITE-14991 > https://issues.apache.org/jira/browse/IGNITE-15235 > https://issues.apache.org/jira/browse/IGNITE-15526 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16235) Races between query execution and table creation
[ https://issues.apache.org/jira/browse/IGNITE-16235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482468#comment-17482468 ] Konstantin Orlov commented on IGNITE-16235: --- LGTM > Races between query execution and table creation > > > Key: IGNITE-16235 > URL: https://issues.apache.org/jira/browse/IGNITE-16235 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > While the IGNITE-16090 fixes the issue, the provided patch lacks of proper > integration test that would verify the fix automatically. So we need to add > the test with follow scenario: > - cluster of 2 or more nodes is started > - create a table and immediately run a query upon that table > To reveal the original issue, we need to delay ditributed event of a table > creation on the node somehow in order to make the query be executed before > the table structures were created. > I believe this is not the only such a test, so we need a general approach to > write tests to verify the cluster behaviour in a concurrent environment. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (IGNITE-16235) Races between query execution and table creation
[ https://issues.apache.org/jira/browse/IGNITE-16235 ] Konstantin Orlov deleted comment on IGNITE-16235: --- was (Author: korlov): LGTM > Races between query execution and table creation > > > Key: IGNITE-16235 > URL: https://issues.apache.org/jira/browse/IGNITE-16235 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > While the IGNITE-16090 fixes the issue, the provided patch lacks of proper > integration test that would verify the fix automatically. So we need to add > the test with follow scenario: > - cluster of 2 or more nodes is started > - create a table and immediately run a query upon that table > To reveal the original issue, we need to delay ditributed event of a table > creation on the node somehow in order to make the query be executed before > the table structures were created. > I believe this is not the only such a test, so we need a general approach to > write tests to verify the cluster behaviour in a concurrent environment. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16402) Fix year check in GridCommandHandler* tests
[ https://issues.apache.org/jira/browse/IGNITE-16402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16402: - Summary: Fix year check in GridCommandHandler* tests (was: Fix year check in the GridCommandHandler* tests) > Fix year check in GridCommandHandler* tests > --- > > Key: IGNITE-16402 > URL: https://issues.apache.org/jira/browse/IGNITE-16402 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.13 > > > Fix year check in the GridCommandHandler* tests: > * GridCommandHandlerClusterByClassTest.testHelp > * GridCommandHandlerClusterByClassTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testHelp -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16402) Fix year check in GridCommandHandler* tests
[ https://issues.apache.org/jira/browse/IGNITE-16402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16402: - Description: Fix year check in GridCommandHandler* tests: * GridCommandHandlerClusterByClassTest.testHelp * GridCommandHandlerClusterByClassTest.testCacheHelp * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp * GridCommandHandlerClusterByClassWithSSLTest.testHelp was: Fix year check in the GridCommandHandler* tests: * GridCommandHandlerClusterByClassTest.testHelp * GridCommandHandlerClusterByClassTest.testCacheHelp * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp * GridCommandHandlerClusterByClassWithSSLTest.testHelp > Fix year check in GridCommandHandler* tests > --- > > Key: IGNITE-16402 > URL: https://issues.apache.org/jira/browse/IGNITE-16402 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.13 > > > Fix year check in GridCommandHandler* tests: > * GridCommandHandlerClusterByClassTest.testHelp > * GridCommandHandlerClusterByClassTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testHelp -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16402) Fix year check in the GridCommandHandler* tests
[ https://issues.apache.org/jira/browse/IGNITE-16402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-16402: Assignee: Amelchev Nikita > Fix year check in the GridCommandHandler* tests > --- > > Key: IGNITE-16402 > URL: https://issues.apache.org/jira/browse/IGNITE-16402 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.13 > > > Fix year check in the GridCommandHandler* tests: > * GridCommandHandlerClusterByClassTest.testHelp > * GridCommandHandlerClusterByClassTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testHelp -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16377) Notification listeners of TableManager should rely on causality tokens when referring to dependee components
[ https://issues.apache.org/jira/browse/IGNITE-16377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16377: - Epic Link: IGNITE-16362 > Notification listeners of TableManager should rely on causality tokens when > referring to dependee components > > > Key: IGNITE-16377 > URL: https://issues.apache.org/jira/browse/IGNITE-16377 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > While handling the notifications, listeners should rely on the fact that the > components that they depend on, won’t return stale or inconsistent data. It > should be guaranteed by causality tokens mechanism. > Listeners of TableManager should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16260) User object serialization performance optimization
[
https://issues.apache.org/jira/browse/IGNITE-16260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-16260:
--
Assignee: Roman Puchkovskiy
> User object serialization performance optimization
> --
>
> Key: IGNITE-16260
> URL: https://issues.apache.org/jira/browse/IGNITE-16260
> Project: Ignite
> Issue Type: Task
>Reporter: Semyon Danilov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> Currently, JDK serialization is quite faster than Ignite's user object
> serialization (AllTypesMessage object):
>
> {code:java}
> Benchmark Mode CntScore
> Error Units
> SerializationMicroBenchmark.jdk_serialization avgt 15 1395605.836
> ± 56061.652 ns/op
> SerializationMicroBenchmark.user_object_serialization avgt 15 3913206.848
> ± 78565.118 ns/op{code}
> During the profiling and benchmarking, I've managed to get these results (I
> also benchmark against kryo), be aware of the change of time unit:
>
>
> {code:java}
> Benchmark Mode Cnt Score
> Error Units
> SerializationMicroBenchmark.jdk_serialization avgt 15 1408.451 ±
> 52.326 us/op
> SerializationMicroBenchmark.kryo_serialization avgt 15 2052.704 ±
> 102.327 us/op
> SerializationMicroBenchmark.user_object_serialization avgt 15 1963.285 ±
> 65.170 us/op {code}
> For simple objects (three primitive fields) I have following results:
> {code:java}
> Benchmark Mode CntScore
> Error Units
> SerializationMicroBenchmark.jdk_serialization avgt 15 948.584 ±
> 80.484 ns/op
> SerializationMicroBenchmark.kryo_serialization avgt 15 588.102 ±
> 13.152 ns/op
> SerializationMicroBenchmark.user_object_serialization avgt 15 636.171 ±
> 66.541 ns/op {code}
> So it seems like JDK serialization is still better for complex objects, but
> not for simple objects. And kryo is the best on simple objects.
> See the branch associated with this issue to inspect the performance tweaks
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16390) Improvements of event listeners for SqlQueryProcessor
[ https://issues.apache.org/jira/browse/IGNITE-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16390: - Epic Link: IGNITE-16362 > Improvements of event listeners for SqlQueryProcessor > - > > Key: IGNITE-16390 > URL: https://issues.apache.org/jira/browse/IGNITE-16390 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Listeners for SqlQueryProcessor should rely on causality tokens while > handling notifications. > Listeners of SqlQueryProcessor should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15945) Class inheritance and effectively final fields
[ https://issues.apache.org/jira/browse/IGNITE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-15945: -- Assignee: (was: Roman Puchkovskiy) > Class inheritance and effectively final fields > -- > > Key: IGNITE-15945 > URL: https://issues.apache.org/jira/browse/IGNITE-15945 > Project: Ignite > Issue Type: Task >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 40m > Remaining Estimate: 0h > > Support inheritance of user objects and polymorphic fields. > During the class instance (de)serialization, the (de)serializer traverses the > fields from the descriptor and writes: > * Field's value class descriptor ID and field data if the declared field's > class is non-final. This allows supporting polymorphic fields. > * Field data without field value class descriptor if declared field's class > is final. In this case, the actual field's value object is guaranteed to be > equal to the declared field class. > See > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16391) Causality tokens implementation
[ https://issues.apache.org/jira/browse/IGNITE-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16391: - Epic Link: IGNITE-16362 Ignite Flags: (was: Docs Required) > Causality tokens implementation > --- > > Key: IGNITE-16391 > URL: https://issues.apache.org/jira/browse/IGNITE-16391 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Umbrella ticket for causality tokens. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16362: - Issue Type: Epic (was: Task) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Epic >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16362: - Ignite Flags: (was: Docs Required,Release Notes Required) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-16362: Assignee: Vyacheslav Koptilin > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16402) Fix year check in the GridCommandHandler* tests
[ https://issues.apache.org/jira/browse/IGNITE-16402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16402: - Fix Version/s: 2.13 > Fix year check in the GridCommandHandler* tests > --- > > Key: IGNITE-16402 > URL: https://issues.apache.org/jira/browse/IGNITE-16402 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Priority: Minor > Fix For: 2.13 > > > Fix year check in the GridCommandHandler* tests: > * GridCommandHandlerClusterByClassTest.testHelp > * GridCommandHandlerClusterByClassTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testCacheHelp > * GridCommandHandlerClusterByClassWithSSLTest.testHelp -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-16362: Assignee: (was: Vyacheslav Koptilin) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16377) Notification listeners of TableManager should rely on causality tokens when referring to dependee components
[ https://issues.apache.org/jira/browse/IGNITE-16377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16377: - Epic Link: (was: IGNITE-16362) > Notification listeners of TableManager should rely on causality tokens when > referring to dependee components > > > Key: IGNITE-16377 > URL: https://issues.apache.org/jira/browse/IGNITE-16377 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > While handling the notifications, listeners should rely on the fact that the > components that they depend on, won’t return stale or inconsistent data. It > should be guaranteed by causality tokens mechanism. > Listeners of TableManager should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16363) Provide a guarantee of completeness of pre-recovery actions
[ https://issues.apache.org/jira/browse/IGNITE-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16363: - Epic Link: (was: IGNITE-16362) > Provide a guarantee of completeness of pre-recovery actions > --- > > Key: IGNITE-16363 > URL: https://issues.apache.org/jira/browse/IGNITE-16363 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > We need to be sure that recovery should perform on the node after it has > joined physical topology and has been validated via node join protocol. > Necessary prerequisites for the recovery start are following: > * the node has retrieved the information and metastorage group from Vault; > * the node has received a join response in case of non-standalone mode, > meaning that the node is validated and is allowed to join the cluster. This > step can be mocked for now; > * all components have started and subscribed on configuration updates and > events. After this, notifications should be allowed and the recovery actually > starts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16365) Implement a logic of recovery finishing
[ https://issues.apache.org/jira/browse/IGNITE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16365: - Epic Link: (was: IGNITE-16362) > Implement a logic of recovery finishing > --- > > Key: IGNITE-16365 > URL: https://issues.apache.org/jira/browse/IGNITE-16365 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > The key point of local state recovery is catching of latest revision applied > in metastorage to apply it locally. In case of standalone mode the node > should finish recovery after restoring components' state from vault, > otherwise it should retrieve updates from metastorage. Notifications from > metastorage should be allowed on recovery stage after all components have > started, and recovery should continue until the node has reached minimal > acceptable difference between itself and the cluster. > Need to implement: > * methods for getting the minimal available revision in Metastorage and the > last applied one; > * some recovery processor class intended to do the logic related to catching > last metastorage revision, and responsile for firing FinishedRecovery message > to cluster management group. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16368) Implement a futures for causality tokens
[ https://issues.apache.org/jira/browse/IGNITE-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16368: - Epic Link: (was: IGNITE-16362) > Implement a futures for causality tokens > > > Key: IGNITE-16368 > URL: https://issues.apache.org/jira/browse/IGNITE-16368 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > One can create a future for some component with some causality token. This > future completes when this component has handled all notifications having the > given causality token. More formally, it completes when the component handles > notification about storage revision update having the given causality token. > When a component listener handles a notification, it must execute the code > that relies on the state of the depended component, after completion of the > future, created for this component with a certain causality token received > within the notification. This guarantees that notifications will be handled > by component listeners in a proper order. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16391) Causality tokens implementation
[ https://issues.apache.org/jira/browse/IGNITE-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16391: - Epic Link: (was: IGNITE-16362) > Causality tokens implementation > --- > > Key: IGNITE-16391 > URL: https://issues.apache.org/jira/browse/IGNITE-16391 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Umbrella ticket for causality tokens. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16380) Add CMG manager
[ https://issues.apache.org/jira/browse/IGNITE-16380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16380: - Epic Link: (was: IGNITE-16362) > Add CMG manager > --- > > Key: IGNITE-16380 > URL: https://issues.apache.org/jira/browse/IGNITE-16380 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Add a manager that will server a cluster management RAFT group (CMG). > It is getting a list of peers from the initial (local) configuration, then > starting a RAFT group. > The RAFT group should store a list of Metastorage nodes. The first > implementation may decide the same nodes (as CMG) as Metastorage peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16390) Improvements of event listeners for SqlQueryProcessor
[ https://issues.apache.org/jira/browse/IGNITE-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16390: - Epic Link: (was: IGNITE-16362) > Improvements of event listeners for SqlQueryProcessor > - > > Key: IGNITE-16390 > URL: https://issues.apache.org/jira/browse/IGNITE-16390 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Listeners for SqlQueryProcessor should rely on causality tokens while > handling notifications. > Listeners of SqlQueryProcessor should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16367) Notification about storage revision update
[ https://issues.apache.org/jira/browse/IGNITE-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16367: - Epic Link: (was: IGNITE-16362) > Notification about storage revision update > -- > > Key: IGNITE-16367 > URL: https://issues.apache.org/jira/browse/IGNITE-16367 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Every event should produce a storage revision update notification along with > all the rest required notifications. This notification should have the same > causality token, It should be guaranteed that this notification will be the > last of all notifications triggered by one certain event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16366) Add causality tokens for notifications
[
https://issues.apache.org/jira/browse/IGNITE-16366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16366:
-
Epic Link: (was: IGNITE-16362)
> Add causality tokens for notifications
> --
>
> Key: IGNITE-16366
> URL: https://issues.apache.org/jira/browse/IGNITE-16366
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Cluster-wide events, such as, for example, configuration changes or
> Metastorage updates, trigger notifications that are propagated to the nodes
> and therefore, to components. Every event can trigger several notifications.
> Every notification has a causality token. Notifications triggered by the same
> event have the same causality token.
> {{Tokens should be added to
> org.apache.ignite.internal.manager.EventParameters}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16371) Improvements of start() methods of Ignite components for local recovery
[ https://issues.apache.org/jira/browse/IGNITE-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16371: - Epic Link: (was: IGNITE-16362) > Improvements of start() methods of Ignite components for local recovery > --- > > Key: IGNITE-16371 > URL: https://issues.apache.org/jira/browse/IGNITE-16371 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > These methods should take into account that the listeners should be started > on components' start, and notifications for these listeners are allowed after > the start of all components has been completed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16372) Make a research about possibility of performing a rebalance on recovery
[ https://issues.apache.org/jira/browse/IGNITE-16372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16372: - Epic Link: (was: IGNITE-16362) > Make a research about possibility of performing a rebalance on recovery > --- > > Key: IGNITE-16372 > URL: https://issues.apache.org/jira/browse/IGNITE-16372 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > A possible optimization is to perform rebalance on node recovery, to make > sure that in the moment when the node joins logical topology it is ready to > serve user load. Research is needed to check whether it's possible to > distinguish the rebalance and user load to allow the former on recovery > without allowing the latter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16369) Any() mode for the component listeners
[ https://issues.apache.org/jira/browse/IGNITE-16369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16369: - Epic Link: (was: IGNITE-16362) > Any() mode for the component listeners > -- > > Key: IGNITE-16369 > URL: https://issues.apache.org/jira/browse/IGNITE-16369 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > The component listeners should have ability to be configured in a way to > handle properly notifications for any component. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16362: - Issue Type: Task (was: Epic) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
