[jira] [Assigned] (IGNITE-16345) flaky test KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes
[ https://issues.apache.org/jira/browse/IGNITE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-16345: -- Assignee: (was: Yury Gerzhedovich) > flaky test KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes > > > Key: IGNITE-16345 > URL: https://issues.apache.org/jira/browse/IGNITE-16345 > Project: Ignite > Issue Type: Bug >Reporter: Yury Gerzhedovich >Priority: Blocker > Labels: ignite-3 > > test > [KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes|https://ci.ignite.apache.org/test/3137655872791539803?currentProjectId=ignite3_Test&branch=pull%2F566] > is flaky. > 16:50:36 [INFO] Running > org.apache.ignite.internal.table.RecordBinaryViewOperationsTest > 16:50:36 > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest > 16:50:36 putGetAllTypes > 16:50:36 org.apache.ignite.lang.IgniteException > 16:50:36 org.apache.ignite.lang.IgniteException: Failed to read column: > colIdx1 > at > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes(KeyValueViewOperationsSimpleSchemaTest.java:328) > Caused by: org.apache.ignite.lang.IgniteException: Failed to read > column: colIdx1 > at > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes(KeyValueViewOperationsSimpleSchemaTest.java:328) > Caused by: > org.apache.ignite.internal.schema.marshaller.MarshallerException: Failed to > read column: colIdx1 > at > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes(KeyValueViewOperationsSimpleSchemaTest.java:328) > Caused by: > org.apache.ignite.internal.schema.marshaller.MarshallerException: Failed to > read column [id=1] > at > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes(KeyValueViewOperationsSimpleSchemaTest.java:328) > Caused by: java.lang.IndexOutOfBoundsException > at > org.apache.ignite.internal.table.KeyValueViewOperationsSimpleSchemaTest.putGetAllTypes(KeyValueViewOperationsSimpleSchemaTest.java:328) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15948) Implement class structure change handling
[ https://issues.apache.org/jira/browse/IGNITE-15948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-15948: -- Assignee: Roman Puchkovskiy > Implement class structure change handling > - > > Key: IGNITE-15948 > URL: https://issues.apache.org/jira/browse/IGNITE-15948 > Project: Ignite > Issue Type: Task >Reporter: Semyon Danilov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > User objects may change their class definition (e.g. class can lose its final > modifier, can become private, or in other means inaccessible). Ignite should > make the best effort at merging different versions of descriptors and parsing > objects. > See > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#handling-class-structure-changes -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15945) Class inheritance and effectively final fields
[ https://issues.apache.org/jira/browse/IGNITE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482293#comment-17482293 ] Roman Puchkovskiy commented on IGNITE-15945: What was implemented differs a bit from the original description. Even when we know that a field can only contain a value of a concrete type, it can still also contain a null. For this reason, nulls bitmaps are written. > 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 > > > 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] [Comment Edited] (IGNITE-15945) Class inheritance and effectively final fields
[ https://issues.apache.org/jira/browse/IGNITE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482293#comment-17482293 ] Roman Puchkovskiy edited comment on IGNITE-15945 at 1/26/22, 7:06 AM: -- What was implemented differs a bit from the original description. Even when we know that a field can only contain a value of a concrete type, it can still also contain a null. For this reason, nulls bitmaps are written in addition. was (Author: rpuch): What was implemented differs a bit from the original description. Even when we know that a field can only contain a value of a concrete type, it can still also contain a null. For this reason, nulls bitmaps are written. > 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 > > > 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] [Comment Edited] (IGNITE-16046) Calcite engine. Double JOIN hangs on optimization phase
[
https://issues.apache.org/jira/browse/IGNITE-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482284#comment-17482284
]
Evgeny Stanilovsky edited comment on IGNITE-16046 at 1/26/22, 6:42 AM:
---
seems we need to investigate improvements from [1] and usage of
CoreRules#JOIN_TO_MULTI_JOIN -> CoreRules#MULTI_JOIN_OPTIMIZE
[1] https://issues.apache.org/jira/browse/CALCITE-4515
was (Author: zstan):
seems we need to investigate improvements from [1] and usage of
CoreRules#MULTI_JOIN_OPTIMIZE
[1] https://issues.apache.org/jira/browse/CALCITE-4515
> Calcite engine. Double JOIN hangs on optimization phase
> ---
>
> Key: IGNITE-16046
> URL: https://issues.apache.org/jira/browse/IGNITE-16046
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Attachments: IGNITE-16046_Combinatorial_explosions.patch
>
>
> Reproducer:
> {noformat}
> CREATE TABLE T1(A INT, B INT);
> CREATE TABLE T2(A INT, C INT);
> CREATE TABLE T3(B INT, C INT);
> SELECT * FROM T1 JOIN T2 ON (T1.A = T2.A) JOIN T3 ON (T1.B = T3.B AND T2.C =
> T3.C);
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16046) Calcite engine. Double JOIN hangs on optimization phase
[
https://issues.apache.org/jira/browse/IGNITE-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482284#comment-17482284
]
Evgeny Stanilovsky commented on IGNITE-16046:
-
seems we need to investigate improvements from [1] and usage of
CoreRules#MULTI_JOIN_OPTIMIZE
[1] https://issues.apache.org/jira/browse/CALCITE-4515
> Calcite engine. Double JOIN hangs on optimization phase
> ---
>
> Key: IGNITE-16046
> URL: https://issues.apache.org/jira/browse/IGNITE-16046
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Attachments: IGNITE-16046_Combinatorial_explosions.patch
>
>
> Reproducer:
> {noformat}
> CREATE TABLE T1(A INT, B INT);
> CREATE TABLE T2(A INT, C INT);
> CREATE TABLE T3(B INT, C INT);
> SELECT * FROM T1 JOIN T2 ON (T1.A = T2.A) JOIN T3 ON (T1.B = T3.B AND T2.C =
> T3.C);
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client
[
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482212#comment-17482212
]
Sergey Korotkov commented on IGNITE-16375:
--
As far as the second part - checking the existing tests. I have run the TC with
the assertion in place and will check if any problem exist.
> GridAbstractTest.startClientGrid() method does not guarantee that started
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration,
> {{GridAbstractTest.startClientGrid()}} will start the server node, while
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred).
> See reproducer at [^Client_node_start_failed_reproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client
[
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482212#comment-17482212
]
Sergey Korotkov edited comment on IGNITE-16375 at 1/26/22, 3:38 AM:
As far as the second part - checking the existing tests. I have run the TC with
the assertion in place and will check if any problem exists.
was (Author: JIRAUSER279895):
As far as the second part - checking the existing tests. I have run the TC with
the assertion in place and will check if any problem exist.
> GridAbstractTest.startClientGrid() method does not guarantee that started
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration,
> {{GridAbstractTest.startClientGrid()}} will start the server node, while
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred).
> See reproducer at [^Client_node_start_failed_reproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client
[
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482210#comment-17482210
]
Sergey Korotkov commented on IGNITE-16375:
--
I have analysed the issue.
There are several fuctions to start the client nodes with different set of
parameters. But only two of them do real start. Others just call these two.
The first one *_startClientGrid(cfg)_* gets the ignite configuration as a
parameter and forces the client mode explicitely.
The second one *_startClientGrid(name)_* obtains the ignite configuration via
the protected _*getConfiguration(name)*_ method which can be overriden by the
test. And tries to force client mode implicitely just by calling the
IgnitioEx.setClientMode(true) which may be completely ignored by the test.
Summary is in the below table:
||Function||Calls to do real work||Does real start||Set client mode via||How
get the cfg||Affected by the issue||
|{color:#00875a}startClientGrid(name, cfg){color}|{color:#00875a} ->
startClientGrid(cfg){color}| | | |{color:#00875a}No{color}|
|{color:#00875a}startClientGrid(cfg){color}|{color:#00875a} ->
startGrid(cfg){color}|{color:#00875a}Yes{color}|{color:#00875a}cfg.setClientMode(true){color}|{color:#00875a}via
parameter{color}|{color:#00875a}No{color}|
|{color:#de350b}startClientGridsMultiThreaded{color}|{color:#de350b} ->
startClientGrid(idx){color}| | | |{color:#de350b}Yes{color}|
|{color:#de350b}startClientGrid(){color}|{color:#de350b} ->
startClientGrid(name){color}| | | |{color:#de350b}Yes{color}|
|{color:#de350b}startClientGrid(idx){color}|{color:#de350b} ->
startClientGrid(name){color}| | | |{color:#de350b}Yes{color}|
|{color:#de350b}startClientGrid(idx, dep_rslvr){color}|{color:#de350b} ->
startClientGrid(name){color}| | | |{color:#de350b}Yes{color}|
|{color:#de350b}startClientGrid(name){color}|{color:#de350b} ->
startGrid(name){color}|{color:#de350b}Yes{color}|{color:#de350b}IgnitionEx.setClientMode(true){color}|{color:#de350b}devegates
to getConfiguration(name){color}|{color:#de350b}Yes{color}|
---
[~av] So the question is do we want to have two different behaviour for
starting client nodes? One which just forces the client mode and the second
which produces the exception. Does it make sence to just force the client mode
in both cases?
> GridAbstractTest.startClientGrid() method does not guarantee that started
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration,
> {{GridAbstractTest.startClientGrid()}} will start the server node, while
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred).
> See reproducer at [^Client_node_start_failed_reproducer.patch]
--
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=17481932#comment-17481932
]
Ignite TC Bot commented on IGNITE-15450:
{panel:title=Branch: [pull/9760/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9760/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6383164]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testSnapshotRestoreSynchronously - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterSnapshotCreateSynchronously - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSSLTest.testSnapshotRestoreSynchronously - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSSLTest.testClusterSnapshotCreateSynchronously -
PASSED{color}
{color:#8b}Control Utility (Zookeeper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6383163]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testSnapshotRestoreSynchronously - PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterSnapshotCreateSynchronously - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6383217&buildTypeId=IgniteTests24Java8_RunAll]
> 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: 10m
> 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] [Assigned] (IGNITE-16269) JDBC. Support for Statement#maxRows
[
https://issues.apache.org/jira/browse/IGNITE-16269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16269:
-
Assignee: Vladimir Ermakov
> JDBC. Support for Statement#maxRows
> ---
>
> Key: IGNITE-16269
> URL: https://issues.apache.org/jira/browse/IGNITE-16269
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> A {{maxRows}} attribute is stored into statement and passed to the
> QueryExecuteRequest, but ignored on the server side.
> Let's add support for this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16268) JDBC. Validation of statement type should be done before its execution
[
https://issues.apache.org/jira/browse/IGNITE-16268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16268:
-
Assignee: Vladimir Ermakov
> JDBC. Validation of statement type should be done before its execution
> --
>
> Key: IGNITE-16268
> URL: https://issues.apache.org/jira/browse/IGNITE-16268
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> Currently, it's possible to execute DML statement such as INSERT, UPDATE, or
> DELETE with {{Statement#executeQuery}} method. The statement will be
> executed, and exception will be thrown after result of the execution will be
> received.
> {code:java}
> class JdbcStatement {
> public ResultSet executeQuery(String sql) throws SQLException {
> ...
> ResultSet rs = getResultSet();
> if (rs == null) {
> throw new SQLException("The query isn't SELECT query: " + sql,
> SqlStateCode.PARSING_EXCEPTION);
> }
> ...
> }
> public ResultSet getResultSet() throws SQLException {
> ...
> JdbcResultSet rs = resSets.get(curRes);
> if (!rs.isQuery()) {
> return null;
> }
> ...
> }
> {code}
> Let's validate the type of the statement before its execution.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16219) JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix
[ https://issues.apache.org/jira/browse/IGNITE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16219: --- Component/s: sql > JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix > - > > Key: IGNITE-16219 > URL: https://issues.apache.org/jira/browse/IGNITE-16219 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > ItJdbcJoinsSelfTest1.testJoin runs correctly in local, but in teamcity > java.lang.AssertionError is appeared. Should be investigated. Logs: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner/6343350 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-15251) JDBC driver for 3.0: Support DML/DDL queries.
[ https://issues.apache.org/jira/browse/IGNITE-15251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-15251. Resolution: Invalid > JDBC driver for 3.0: Support DML/DDL queries. > - > > Key: IGNITE-15251 > URL: https://issues.apache.org/jira/browse/IGNITE-15251 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Extend Statement functionality for DML/DDL queries. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16394) Provide enum of released versions to compatibility tests and extensions
[ https://issues.apache.org/jira/browse/IGNITE-16394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16394: - Summary: Provide enum of released versions to compatibility tests and extensions (was: Provide enum of released versions to compatibility tests) > Provide enum of released versions to compatibility tests and extensions > --- > > 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: 10m > 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-16394) Provide enum of released versions to compatibility tests
[ https://issues.apache.org/jira/browse/IGNITE-16394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16394: - Summary: Provide enum of released versions to compatibility tests (was: Provide enum of released versions to compatibility tests and extensions) > 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: 10m > 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-16394) Provide enum of released versions to compatibility tests
[ https://issues.apache.org/jira/browse/IGNITE-16394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16394: - Fix Version/s: 2.13 > 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: 10m > 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] [Created] (IGNITE-16394) Provide enum of released versions to compatibility tests
Amelchev Nikita created IGNITE-16394: Summary: 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 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-16393) Move network's user object serialization to the user thread
[ https://issues.apache.org/jira/browse/IGNITE-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-16393: Summary: Move network's user object serialization to the user thread (was: Move user object serialization in network to the user thread) > Move network's user object serialization to the user thread > --- > > Key: IGNITE-16393 > URL: https://issues.apache.org/jira/browse/IGNITE-16393 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > > At this moment, user object serialization is performed during the direct > marshalling stage on the IO thread, which can affect network throughput. Need > to investigate means and options to move this marshalling to the user thread. > One of the options is to generate byte[] fields for every `@Marshallable` > field so they can be written to the socket/read from the socket during the > direct marshalling stage. However, this can affect the user thread (or it can > even be accidentally performed on the IO thread. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16393) Move user object serialization in network to the user thread
Semyon Danilov created IGNITE-16393: --- Summary: Move user object serialization in network to the user thread Key: IGNITE-16393 URL: https://issues.apache.org/jira/browse/IGNITE-16393 Project: Ignite Issue Type: Task Components: networking Reporter: Semyon Danilov At this moment, user object serialization is performed during the direct marshalling stage on the IO thread, which can affect network throughput. Need to investigate means and options to move this marshalling to the user thread. One of the options is to generate byte[] fields for every `@Marshallable` field so they can be written to the socket/read from the socket during the direct marshalling stage. However, this can affect the user thread (or it can even be accidentally performed on the IO thread. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16072) Add configurable throttling for the spanshot process
[ https://issues.apache.org/jira/browse/IGNITE-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-16072: - Assignee: Pavel Pereslegin > Add configurable throttling for the spanshot process > > > Key: IGNITE-16072 > URL: https://issues.apache.org/jira/browse/IGNITE-16072 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, ise > Fix For: 2.13 > > > We want to add configurable throttling to the number of threads that perform > a snapshot operation. The IGNITE-16014 have introduced the pool size > configuration property, however, it is still possible that a node can become > overloaded and unresponsive due to its attempts to copy data files on very > slow HDDs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16392) [Native Persistence 3.0] PageMemoryNoImpl porting
Ivan Bessonov created IGNITE-16392: -- Summary: [Native Persistence 3.0] PageMemoryNoImpl porting Key: IGNITE-16392 URL: https://issues.apache.org/jira/browse/IGNITE-16392 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov We need to port common things like offheap lock, data storage configuration, memory region interfaces, itc. to simplify further porting of other components. Many tests rely on PageMemoryNoStoreImpl, it would be convenient to port them without drastic changes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16313) Bugyard feedback #48: Fix the outdated title
[ https://issues.apache.org/jira/browse/IGNITE-16313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita A. Safonov resolved IGNITE-16313. Resolution: Won't Fix > Bugyard feedback #48: Fix the outdated title > > > Key: IGNITE-16313 > URL: https://issues.apache.org/jira/browse/IGNITE-16313 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.11.1 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: documentaion, documentation > Fix For: 2.11.1 > > > All the instances of "Yardstick Framework" in this article > [https://ignite.apache.org/docs/latest/perf-and-troubleshooting/yardstick-benchmarking#] > should be changed to "Android 360°". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (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=17481846#comment-17481846
]
Pavel Pereslegin edited comment on IGNITE-15450 at 1/25/22, 2:28 PM:
-
The final solution is to add a "wait" option to wait for the entire operation
to complete.
*Create*
{noformat}
Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
{noformat}
*Restore*
{noformat}
Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups
group1,...groupN]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
group1,...groupN - Cache group names.
{noformat}
was (Author: xtern):
The final solution is to add a "wait" flag to wait for the entire operation to
complete.
*Create*
{noformat}
Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
{noformat}
*Restore*
{noformat}
Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups
group1,...groupN]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
group1,...groupN - Cache group names.
{noformat}
> 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: 10m
> 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-15000) putAllConflict removeAllConfict support in thin client
[
https://issues.apache.org/jira/browse/IGNITE-15000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15000:
-
Description:
{{IgniteInternalCache}} contains methods {{putAllConfict}},
{{removeAllConfict}} that can be used to perform put, remove operations with
entry {{GridCacheVersion}}.
To implement multi-cluster replication using thin clients we need to add these
methods to the thin client protocol.
was:
`IgniteInternalCache` contains methods `putAllConfict`, `removeAllConfict` that
can be used to perform put, remove operations with entry `GridCacheVersion`.
To implement multi-cluster replication using thin clients we need to add these
methods to the thin client protocol.
> putAllConflict removeAllConfict support in thin client
> --
>
> Key: IGNITE-15000
> URL: https://issues.apache.org/jira/browse/IGNITE-15000
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> {{IgniteInternalCache}} contains methods {{putAllConfict}},
> {{removeAllConfict}} that can be used to perform put, remove operations with
> entry {{GridCacheVersion}}.
> To implement multi-cluster replication using thin clients we need to add
> these methods to the thin client protocol.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (IGNITE-15330) Read Repair should support strategies
[ https://issues.apache.org/jira/browse/IGNITE-15330 ]
Anton Vinogradov deleted comment on IGNITE-15330:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/9661/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9661/head] Base: [master] : New Tests
(70)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
40|https://ci.ignite.apache.org/viewLog.html?buildId=6328302]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testRepairNonExistentCache[strategy=PRIMARY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testCacheFilter[strategy=PRIMARY] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxVersionOnly[strategy=PRIMARY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxValueAndVersion[strategy=MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testRepairNonExistentCache[strategy=LWW]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testCacheFilter[strategy=LWW] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxVersionOnly[strategy=LWW]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxValueAndVersion[strategy=PRIMARY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testRepairNonExistentCache[strategy=CHECK_ONLY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testCacheFilter[strategy=CHECK_ONLY] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testAtomicAndTxVersionOnly[strategy=CHECK_ONLY]
- PASSED{color}
... and 29 new tests
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6328329]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=false,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=true,walMode=LOG_ONLY,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true,walMode=LOG_ONLY,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=false,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false,walMode=BACKGROUND,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false,walMode=LOG_ONLY,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true,walMode=LOG_ONLY,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true,walMode=LOG_ONLY,metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1977493952@59cda16e,pageSz=8,192]
- PASSED{color}
... and 19 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6328355&buildTypeId=IgniteTests24Java8_RunAll]
> Read Re
[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=17481846#comment-17481846
]
Pavel Pereslegin commented on IGNITE-15450:
---
The final solution is to add a "wait" flag to wait for the entire operation to
complete.
*Create*
{noformat}
Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
{noformat}
*Restore*
{noformat}
Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups
group1,...groupN]
Parameters:
snapshot_name - Snapshot name.
wait - Wait for the entire operation to complete. Otherwise,
the operation will be performed in the background, and the command will
immediately return control.
group1,...groupN - Cache group names.
{noformat}
> 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: 10m
> 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] [Commented] (IGNITE-15330) Read Repair should support strategies
[
https://issues.apache.org/jira/browse/IGNITE-15330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481843#comment-17481843
]
Ignite TC Bot commented on IGNITE-15330:
{panel:title=Branch: [pull/9661/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9661/head] Base: [master] : New Tests
(520)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
40|https://ci.ignite.apache.org/viewLog.html?buildId=6382490]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxValueAndVersion[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testRepairNonExistentCache[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testCacheFilter[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxVersionOnly[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testAtomicAndTxValueAndVersion[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testRepairNonExistentCache[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testCacheFilter[strategy=RELATIVE_MAJORITY] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyTest.testAtomicAndTxVersionOnly[strategy=RELATIVE_MAJORITY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testRepairNonExistentCache[strategy=PRIMARY]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testCacheFilter[strategy=PRIMARY] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyBinaryTest.testAtomicAndTxVersionOnly[strategy=PRIMARY]
- PASSED{color}
... and 29 new tests
{color:#8b}Consistency{color} [[tests
480|https://ci.ignite.apache.org/viewLog.html?buildId=6382542]]
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=PESSIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=false, misses=false,
nulls=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=PESSIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=false, misses=false,
nulls=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=PESSIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=false, misses=true,
nulls=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=PESSIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=false, misses=true, nulls=true]
- PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=true, misses=false, nulls=false] -
PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=true, misses=false, nulls=true] -
PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=true, misses=true, nulls=false] -
PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=true, misses=true, nulls=true] -
PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=false, misses=false, nulls=false]
- PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=false, misses=false, nulls=true] -
PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ReplicatedExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=SERIALIZABLE, getEntry=true, async=false, misses=true, nulls=false] -
PASSED{color}
... and 469 new tests
{panel}
[TeamCi
[jira] [Updated] (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:all-tabpanel ] Pavel Pereslegin updated IGNITE-15450: -- Description: 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. was: 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. > 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: 10m > 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-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:all-tabpanel ] Pavel Pereslegin updated IGNITE-15450: -- Summary: Add special option to run snapshot commands (create/restore) synchronously. (was: Snapshot restore control.sh command should display a user-friendly error about existing caches.) > 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: 10m > 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] [Commented] (IGNITE-16315) Calcite engine. Query start request contains a lot of data
[
https://issues.apache.org/jira/browse/IGNITE-16315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481806#comment-17481806
]
Evgeny Stanilovsky commented on IGNITE-16315:
-
[~alex_pl] i fill some comments.
> Calcite engine. Query start request contains a lot of data
> --
>
> Key: IGNITE-16315
> URL: https://issues.apache.org/jira/browse/IGNITE-16315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> For simple queries SQL engine most of the time spend in writing/reading query
> start requests, which contains a lot of data. Nested instances of
> {{ColocationGroup}} class contain assignments for each partition
> ({{{}List>{}}}). Transferred size can be reduced if we compact
> assignments somehow. The target colocation group from fragment description
> contains redundant synthetic partitions, this also can be optimized.
> Messages workflow is not optimal too. First, we send {{QueryStartRequest}} to
> the remote nodes, remotes reply with the QueryStartResponse messages. After
> that remotes send batches with data to the target nodes and receive acks for
> each batch (acks required to limit inbox workload). When query execution is
> finished, the node initiator sends {{QueryCloseMessage}} to the remote nodes,
> remotes close queries, and sends back {{ErrorMessage}} to the initiator with
> the {{ExecutionCancelledException}} error (which is ignored on the initiator
> node).
> Also, some other optimizations are possible. Proposed changes:
> * Implement compaction of assignments of {{ColocationGroup}}
> * Reduce target colocation group partitions count
> * Fix caching of query plans (store original SQL as key, not parsed SQL, to
> avoid redundant parsing)
> * Change messages workflow (don't send ack messages for the last batch since
> it is redundant, self-close remote queries, and don't send close query
> messages to remote nodes, if we know for sure that it's already self-closed,
> don't send query start response if we already have sent batch for the same
> fragment before)
> * Reduce count of {{RexBuilder}} creation on the execution phase (RexBuilder
> is stateless and can be used one static instance)
> * Reduce count of Calcite types creation on the execution phase
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15913) Merge SQL calcite running query registry to 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-15913: - Assignee: Konstantin Orlov > Merge SQL calcite running query registry to 3.0 > --- > > Key: IGNITE-15913 > URL: https://issues.apache.org/jira/browse/IGNITE-15913 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Adopt the query registry patch (IGNITE-12991) for the Ignite 3.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15913) Merge SQL calcite running query registry to 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-15913: - Assignee: (was: Taras Ledkov) > Merge SQL calcite running query registry to 3.0 > --- > > Key: IGNITE-15913 > URL: https://issues.apache.org/jira/browse/IGNITE-15913 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Adopt the query registry patch (IGNITE-12991) for the Ignite 3.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16257) Implement readUnshared()/writeUnshared() for User Object Serialization
[ https://issues.apache.org/jira/browse/IGNITE-16257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481786#comment-17481786 ] Roman Puchkovskiy commented on IGNITE-16257: Thank you for your review > Implement readUnshared()/writeUnshared() for User Object Serialization > -- > > Key: IGNITE-16257 > URL: https://issues.apache.org/jira/browse/IGNITE-16257 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 20m > Remaining Estimate: 0h > > ObjectOutputStream has writeUnshared() and ObjectInputStream has > readUnshared() methods that differ from writeObject() and readObject() > methods in some aspects (see their javadocs). > We probably need to support this difference. -- 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 ] Denis Chudov updated IGNITE-16362: -- Description: *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. (was: *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. ) > 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 ] Eduard Rakhmankulov updated IGNITE-16362: - Description: *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. was:*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. > 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] [Created] (IGNITE-16391) Causality tokens implementation
Denis Chudov created IGNITE-16391: - Summary: Causality tokens implementation Key: IGNITE-16391 URL: https://issues.apache.org/jira/browse/IGNITE-16391 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov Umbrella ticket for causality tokens. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
[ https://issues.apache.org/jira/browse/IGNITE-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16389: -- Attachment: image (1).png > Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop > - > > Key: IGNITE-16389 > URL: https://issues.apache.org/jira/browse/IGNITE-16389 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Priority: Blocker > Labels: ignite-3 > Attachments: image (1).png > > > Test > org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop > is flacky. To reproduce: repeat the test until NPE appears. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16390) Improvements of event listeners for SqlQueryProcessor
Denis Chudov created IGNITE-16390: - Summary: 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 Listeners for SqlQueryProcessor should rely on causality tokens while handling notifications. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
Vladimir Ermakov created IGNITE-16389: - Summary: Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop Key: IGNITE-16389 URL: https://issues.apache.org/jira/browse/IGNITE-16389 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ermakov Test org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop is flacky. To reproduce: repeat the test until NPE appears. -- 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 ] Denis Chudov updated IGNITE-16377: -- Summary: Notification listeners of TableManager should rely on causality tokens when referring to dependee components (was: Notification listeners should rely on causality tokens when referring to dependee components) > 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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16388) Fix stale TODOs in network
Semyon Danilov created IGNITE-16388: --- Summary: Fix stale TODOs in network Key: IGNITE-16388 URL: https://issues.apache.org/jira/browse/IGNITE-16388 Project: Ignite Issue Type: Task Components: networking Reporter: Semyon Danilov Assignee: Semyon Danilov Fix For: 3.0.0-alpha5 There are two TODOs for the already resolved ticket IGNITE-14538 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16386) clusterId not set in CacheVersionConflictResolverImpl after restart
[ https://issues.apache.org/jira/browse/IGNITE-16386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481782#comment-17481782 ] Nikolay Izhikov commented on IGNITE-16386: -- https://ci2.ignite.apache.org/viewLog.html?buildId=6284647&tab=queuedBuildOverviewTab - tests run > clusterId not set in CacheVersionConflictResolverImpl after restart > --- > > Key: IGNITE-16386 > URL: https://issues.apache.org/jira/browse/IGNITE-16386 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Labels: IEP-59 > > clusterId not set in CacheVersionConflictResolverImpl instance after node > restart. -- 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: Summary: Sql. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. Incorrect grouping reset during rewind. (was: Slq. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. Incorrect grouping reset during rewind.) > 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 > > 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] [Updated] (IGNITE-16326) Prepare Documentation for the AI Alpha 4 Release
[ https://issues.apache.org/jira/browse/IGNITE-16326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16326: - Labels: documentation ignite-3 (was: documentation) > Prepare Documentation for the AI Alpha 4 Release > > > Key: IGNITE-16326 > URL: https://issues.apache.org/jira/browse/IGNITE-16326 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 3.0.0-alpha4 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: documentation, ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to document the following functionality of the upcoming release: > - DDL commands > - Transactions functionality > - Table views: KeyValueView, RecordView, and RecordBinaryView -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16379) Extend raft configuration changes' listener with onChangePeersError
[
https://issues.apache.org/jira/browse/IGNITE-16379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16379:
-
Labels: ignite-3 (was: )
> Extend raft configuration changes' listener with onChangePeersError
> ---
>
> Key: IGNITE-16379
> URL: https://issues.apache.org/jira/browse/IGNITE-16379
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> We need to extend raft change configurations listener with
> {{onChangePeersError(errorContext)}} event.
> It must be invoked on any issues, which will be occurred when
> ChangePeersRequest has already been processed and provide the context of
> error: RaftError and message.
>
--
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: - Labels: ignite-3 (was: ) > 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-16353) Implement update of changePeers peers through cancel-rerun strategy
[ https://issues.apache.org/jira/browse/IGNITE-16353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16353: - Labels: ignite-3 (was: ) > Implement update of changePeers peers through cancel-rerun strategy > --- > > Key: IGNITE-16353 > URL: https://issues.apache.org/jira/browse/IGNITE-16353 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We need to handle the case, when we already have in progress raft group > configuration change process, but need to update the list of target peers. > We can do it, only when the current reconfiguration is in the > STAGE_CATCHING_UP phase. > * Implement cancelReconfiguration(leaderTerm), which will > ** Cancel current reconfiguration, if in STAGE_CATCHING_UP phase and returns > true. Returns true if no current reconfiguration too. > ** Returns false otherwise > * Listen planned assignments key. On any updates: check if the current node > is a group leader and if yes: > ** Call cancelReconfiguration and if it returns false - do nothing > ** If true - put received planned list of peers to pending assignments in > metastore > * Also, onLeaderElected() listener must be updated with the similar logic > Then, all needed actions must be started by the further logic on event about > pending assignments update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (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 ] Vyacheslav Koptilin updated IGNITE-16357: - Labels: ignite-3 (was: ) > 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 >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] [Updated] (IGNITE-16343) Update hash and sig links on the Downloads page
[ https://issues.apache.org/jira/browse/IGNITE-16343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16343: - Labels: ignite-3 (was: ) > Update hash and sig links on the Downloads page > --- > > Key: IGNITE-16343 > URL: https://issues.apache.org/jira/browse/IGNITE-16343 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > See dev list thread: > https://lists.apache.org/thread/b693db4rpll8fnwoc01xpspcvjjggsp6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16364) Slq. 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=17481729#comment-17481729 ] Evgeny Stanilovsky commented on IGNITE-16364: - [~korlov] [~tledkov-gridgain] plz review this ports ? > Slq. 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 > > 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-16347) Sql. Support for function TYPEOF. Incorrect plan provided for queries with correlated subquery in project list.
[ https://issues.apache.org/jira/browse/IGNITE-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481727#comment-17481727 ] Evgeny Stanilovsky commented on IGNITE-16347: - [~korlov] [~tledkov-gridgain] plz review this ports ? > Sql. Support for function TYPEOF. Incorrect plan provided for queries with > correlated subquery in project list. > --- > > Key: IGNITE-16347 > URL: https://issues.apache.org/jira/browse/IGNITE-16347 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite3-required, ignite-3 > > Merge [IGNITE-15518|https://issues.apache.org/jira/browse/IGNITE-15518], > [IGNITE-14596|https://issues.apache.org/jira/browse/IGNITE-14596] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (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 ] Denis Chudov reassigned IGNITE-16363: - Assignee: (was: Denis Chudov) > 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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16364) Slq. 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: Description: 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 was: Need to merge: https://issues.apache.org/jira/browse/IGNITE-14991 https://issues.apache.org/jira/browse/IGNITE-15235 > Slq. 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 > > 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] [Updated] (IGNITE-16364) Slq. 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: Summary: Slq. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test. Incorrect grouping reset during rewind. (was: Slq. Supports regexp operators. Remove tableSpoolBroadcastNotRewindable test.) > Slq. 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 > > Need to merge: > https://issues.apache.org/jira/browse/IGNITE-14991 > https://issues.apache.org/jira/browse/IGNITE-15235 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16293) Support multi-platform Docker images
[ https://issues.apache.org/jira/browse/IGNITE-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481695#comment-17481695 ] Petr Ivanov commented on IGNITE-16293: -- s390x is supported unofficially - third-party contributor built them for us. Ticket is good, but someone should start discussion about it on dev-list – will community do it and if will, then how? > Support multi-platform Docker images > > > Key: IGNITE-16293 > URL: https://issues.apache.org/jira/browse/IGNITE-16293 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Stephen Darlington >Priority: Major > > The current Docker image is only built for the x86-64 architecture. It would > be good to have multi-architecture support. [This > blog|https://www.docker.com/blog/multi-platform-docker-builds/] explains how > (basically a second build and a "manifest"). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16293) Support multi-platform Docker images
[ https://issues.apache.org/jira/browse/IGNITE-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481692#comment-17481692 ] Stephen Darlington commented on IGNITE-16293: - We already support two architectures: x86-64 and s390x. Having said that, this ticket was prompted by someone looking for an ARM64 image for an Apple Silicon Mac. > Support multi-platform Docker images > > > Key: IGNITE-16293 > URL: https://issues.apache.org/jira/browse/IGNITE-16293 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Stephen Darlington >Priority: Major > > The current Docker image is only built for the x86-64 architecture. It would > be good to have multi-architecture support. [This > blog|https://www.docker.com/blog/multi-platform-docker-builds/] explains how > (basically a second build and a "manifest"). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int, PRIMARY KEY (ID0, ID1)) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
5. Introduce distributed property to disable these validation for backward
compatibility.
was:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If
[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 ] Vladislav Pyatkov updated IGNITE-16365: --- Description: 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. was: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. > 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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
