[jira] [Updated] (IGNITE-21867) Add new ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Summary: Add new ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values (was: Add an ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values) > Add new ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add an ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Description: h3. Motivation RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but actually it's a business operation one. Within the context of replicaService, there are legitimate reasons for operation to be processed longer than current timeout of 3 seconds, basically it should be possible to wait indefinitely until the transaction times out. But because we don't have transaction timeout and because of possible bugs it seems reasonable to have an operation processing timeout "watchdog" with finite but relatively big configurable value. h3. Definition of Done * Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values. was: h3. Motivation RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but actually it's a business operation one. Within the context of replicaService, there are legitimate reasons for operation to be processed longer than current timeout of 3 seconds, basically it should be possible to wait indefinitely until the transaction times out. But because we don't have transaction timeout and because of possible bugs it seems reasonable to have an operation processing timeout "watchdog" with finite but relatively big configurable value. h3. Definition of Done * Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values > Add an ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > -- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add an ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Summary: Add an ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values (was: Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values) > Add an ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > -- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21875) SQL API cleanup - remove properties and reactive methods
Pavel Tupitsyn created IGNITE-21875: --- Summary: SQL API cleanup - remove properties and reactive methods Key: IGNITE-21875 URL: https://issues.apache.org/jira/browse/IGNITE-21875 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21875) SQL API cleanup - remove properties and reactive methods
[ https://issues.apache.org/jira/browse/IGNITE-21875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21875: Description: * *Statement#properties* are not used * Reactive APIs are not implemented Remove them. > SQL API cleanup - remove properties and reactive methods > > > Key: IGNITE-21875 > URL: https://issues.apache.org/jira/browse/IGNITE-21875 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 3.0.0-beta2 > > > * *Statement#properties* are not used > * Reactive APIs are not implemented > Remove them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21287) Sql. LogicalOrToUnionRule may hang
[ https://issues.apache.org/jira/browse/IGNITE-21287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21287: --- Assignee: Evgeny Stanilovsky > Sql. LogicalOrToUnionRule may hang > -- > > Key: IGNITE-21287 > URL: https://issues.apache.org/jira/browse/IGNITE-21287 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > LogicalOrToUnionRule may hand in case of huge conditions. Let's investigate > possible solutions under this ticket and uncomment the rule. > To reproduce the issue, try to uncomment the rule and run q19 from TPC-H > suite after IGNITE-20880. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19274) Sql. Jdbc client. Support TIMESTAMP WITH LOCAL TIME ZONE type
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831894#comment-17831894
]
Pavel Pereslegin commented on IGNITE-19274:
---
If we continue to convert {{Timestamp}} to {{LocalDateTime}}, we may have to
rework the {{Instant}} to {{Timestamp}} conversion when reading the result set.
Something like this:
{code:java}
if (cls == Instant.class) {
return Timestamp.valueOf(LocalDateTime.ofInstant((Instant) val,
ZoneId.of("UTC")));
{code}
> Sql. Jdbc client. Support TIMESTAMP WITH LOCAL TIME ZONE type
> --
>
> Key: IGNITE-19274
> URL: https://issues.apache.org/jira/browse/IGNITE-19274
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in
> the database is normalized to the database time zone (UTC) and time zone
> offset is not stored as part of the column data. When the data is retrieved,
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets
> but they are equals for now. Also returned representation need to be present
> in user session time zone.
> h5. Update from 26.02.2024:
> Definition of done for this task:
> * Client time zone is passed to server (check other database implementations
> to decide how and when to pass it).
> * Data of type "TIMESTAMP With LOCAL TIME ZONE" can be written/read correctly
> using the dynamic parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
[
https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-21874:
--
Labels: ignite-3 (was: )
> Log versions (java, ignite) to the server log at startup
>
>
> Key: IGNITE-21874
> URL: https://issues.apache.org/jira/browse/IGNITE-21874
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 3.0.0-alpha5
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> We need to log some environments to the server log.
> 1) *OS* and {*}Java version{*}:
> AI2:
> {noformat}
> OS: Linux 5.15.0-100-generic amd64
> [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat}
> AI3:
> {code:java}
> // Nothing
> {code}
> 2) Product version WITH *commit hash*
> AI2 (version and commit has):
> {noformat}
> ver. 2.16.0#20231215-sha1:7bde6a42{noformat}
> AI3 (only version):
> {noformat}
> Apache Ignite ver. 3.0.0-SNAPSHOT{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
[
https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-21874:
--
Description:
We need to log some environments to the server log.
1) *OS* and {*}Java version{*}:
AI2:
{noformat}
OS: Linux 5.15.0-100-generic amd64
[17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat}
AI3:
{code:java}
// Nothing
{code}
2) Product version WITH *commit hash*
AI2 (version and commit has):
{noformat}
ver. 2.16.0#20231215-sha1:7bde6a42{noformat}
AI3 (only version):
{noformat}
Apache Ignite ver. 3.0.0-SNAPSHOT{noformat}
was:
We need to log some environments to the server log.
1) *OS* and {*}Java version{*}:
AI2:
{noformat}
OS: Linux 5.15.0-100-generic amd64
[17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat}
AI3:
{code:java}
// Nothing
{code}
2) Product version WITH *commit hash*
AI2 (version and commit has):
{noformat}
ver. 2.16.0#20231215-sha1:7bde6a42{noformat}
AI3 (only version):
{noformat}
Apache Ignite ver. 3.0.0-SNAPSHOT{noformat}
> Log versions (java, ignite) to the server log at startup
>
>
> Key: IGNITE-21874
> URL: https://issues.apache.org/jira/browse/IGNITE-21874
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 3.0.0-alpha5
>Reporter: Alexander Belyak
>Priority: Major
>
> We need to log some environments to the server log.
> 1) *OS* and {*}Java version{*}:
> AI2:
> {noformat}
> OS: Linux 5.15.0-100-generic amd64
> [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat}
> AI3:
> {code:java}
> // Nothing
> {code}
> 2) Product version WITH *commit hash*
> AI2 (version and commit has):
> {noformat}
> ver. 2.16.0#20231215-sha1:7bde6a42{noformat}
> AI3 (only version):
> {noformat}
> Apache Ignite ver. 3.0.0-SNAPSHOT{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
Alexander Belyak created IGNITE-21874:
-
Summary: Log versions (java, ignite) to the server log at startup
Key: IGNITE-21874
URL: https://issues.apache.org/jira/browse/IGNITE-21874
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 3.0.0-alpha5
Reporter: Alexander Belyak
We need to log some environments to the server log.
1) *OS* and {*}Java version{*}:
AI2:
{noformat}
OS: Linux 5.15.0-100-generic amd64
[17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat}
AI3:
{code:java}
// Nothing
{code}
2) Product version WITH *commit hash*
AI2 (version and commit has):
{noformat}
ver. 2.16.0#20231215-sha1:7bde6a42{noformat}
AI3 (only version):
{noformat}
Apache Ignite ver. 3.0.0-SNAPSHOT{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21873) Sql. The insertion fails if the execution node buffer size is set to 1
[
https://issues.apache.org/jira/browse/IGNITE-21873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21873:
--
Description:
This looks like a degenerate case, but it may still be worth addressing the
issue.
To reproduce this issue you need to set {{Commons.IN_BUFFER_SIZE = 1}}.
And execute DML query, for example:
{code:java}
sql("CREATE TABLE test(id INT PRIMARY KEY)");
sql("INSERT INTO test VALUES (0), (1) ");
{code}
Result:
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.request(ModifyNode.java:130)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.flush(Outbox.java:326)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.push(Outbox.java:166)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:206)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.lambda$flushTuples$1(ModifyNode.java:282)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
~[main/:?]
{noformat}
The problem can be solved by swapping the following lines in the
{{ModifyNode#tryEnd}} method.
{code:java}
downstream().push(context().rowHandler().factory(MODIFY_RESULT).create(updatedRows));
requested = 0; // must come before the 'push()' call
{code}
was:
This seems like a degenerate case, but it may still be worth addressing the
issue.
To reproduce this issue you need to set {{Commons.IN_BUFFER_SIZE = 1}}.
And execute DML query, for example:
{code:java}
sql("CREATE TABLE test(id INT PRIMARY KEY)");
sql("INSERT INTO test VALUES (0), (1) ");
{code}
Result:
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.request(ModifyNode.java:130)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.flush(Outbox.java:326)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.push(Outbox.java:166)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:206)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.lambda$flushTuples$1(ModifyNode.java:282)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
~[main/:?]
{noformat}
The problem can be solved by swapping the following lines in the
{{ModifyNode#tryEnd}} method.
{code:java}
downstream().push(context().rowHandler().factory(MODIFY_RESULT).create(updatedRows));
requested = 0; // must come before the 'push()' call
{code}
> Sql. The insertion fails if the execution node buffer size is set to 1
> --
>
> Key: IGNITE-21873
> URL: https://issues.apache.org/jira/browse/IGNITE-21873
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
>
> This looks like a degenerate case, but it may still be worth addressing the
> issue.
> To reproduce this issue you need to set {{Commons.IN_BUFFER_SIZE = 1}}.
> And execute DML query, for example:
> {code:java}
> sql("CREATE TABLE test(id INT PRIMARY KEY)");
> sql("INSERT INTO test VALUES (0), (1) ");
> {code}
> Result:
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.request(ModifyNode.java:130)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Outbox.flush(Outbox.java:326)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Outbox.push(Outbox.java:166)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:206)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.lambda$flushTuples$1(ModifyNode.java:282)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
> ~[main/:?]
> {noformat}
> The problem can be solved by swapping the following lines in the
> {{ModifyNode#tryEnd}} method.
> {code:java}
> downstream().push(context().rowHandler().factory(MODIFY_RESULT).create(updatedRows));
> requested = 0; // must come before the 'push()' call
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21873) Sql. The insertion fails if the execution node buffer size is set to 1
Pavel Pereslegin created IGNITE-21873:
-
Summary: Sql. The insertion fails if the execution node buffer
size is set to 1
Key: IGNITE-21873
URL: https://issues.apache.org/jira/browse/IGNITE-21873
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
This seems like a degenerate case, but it may still be worth addressing the
issue.
To reproduce this issue you need to set {{Commons.IN_BUFFER_SIZE = 1}}.
And execute DML query, for example:
{code:java}
sql("CREATE TABLE test(id INT PRIMARY KEY)");
sql("INSERT INTO test VALUES (0), (1) ");
{code}
Result:
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.request(ModifyNode.java:130)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.flush(Outbox.java:326)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.Outbox.push(Outbox.java:166)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:206)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.lambda$flushTuples$1(ModifyNode.java:282)
~[main/:?]
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:325)
~[main/:?]
{noformat}
The problem can be solved by swapping the following lines in the
{{ModifyNode#tryEnd}} method.
{code:java}
downstream().push(context().rowHandler().factory(MODIFY_RESULT).create(updatedRows));
requested = 0; // must come before the 'push()' call
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21868) Move the sql RO inflights handling from SqlQueryProcessor to QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit
[ https://issues.apache.org/jira/browse/IGNITE-21868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-21868: -- Description: Handling the transaction inflights in the SqlQueryProcessor is not the best option, (was: *) > Move the sql RO inflights handling from SqlQueryProcessor to > QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit > -- > > Key: IGNITE-21868 > URL: https://issues.apache.org/jira/browse/IGNITE-21868 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > Handling the transaction inflights in the SqlQueryProcessor is not the best > option, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21868) Move the sql RO inflights handling from SqlQueryProcessor to QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit
[ https://issues.apache.org/jira/browse/IGNITE-21868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-21868: -- Description: Handling the transaction inflights in the SqlQueryProcessor is not the best option, should be moved to QueryTransactionContext and QueryTransactionWrapper (was: Handling the transaction inflights in the SqlQueryProcessor is not the best option, ) > Move the sql RO inflights handling from SqlQueryProcessor to > QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit > -- > > Key: IGNITE-21868 > URL: https://issues.apache.org/jira/browse/IGNITE-21868 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > Handling the transaction inflights in the SqlQueryProcessor is not the best > option, should be moved to QueryTransactionContext and QueryTransactionWrapper -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21863) [PerfStat] OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-21863:
--
Assignee: Aleksey Plekhanov
> [PerfStat] OOM when using build-report.sh from performance statistics
> --
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: ise
>
> The problem is reproduced on a large volume collected using
> {code:java}
> ./control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21567) Sql. Conversion from TIMESTAMP to TIMESTAMP_WITH_LOCAL_TIME_ZONE trims millis
[
https://issues.apache.org/jira/browse/IGNITE-21567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21567:
-
Assignee: Pavel Pereslegin
> Sql. Conversion from TIMESTAMP to TIMESTAMP_WITH_LOCAL_TIME_ZONE trims millis
> -
>
> Key: IGNITE-21567
> URL: https://issues.apache.org/jira/browse/IGNITE-21567
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Conversion from TIMESTAMP to TIMESTAMP_WITH_LOCAL_TIME_ZONE loses precision
> {code:java}
> String ts = "1992-01-18 02:30:00.123";
> assertQuery(format("select TIMESTAMP '{}'::TIMESTAMP WITH LOCAL TIME ZONE ",
> ts))
> .returns(LocalDateTime.parse(ts,
> DateTimeFormatter.ofPattern("-MM-dd HH:mm:ss.SSS"))
> .atZone(ZoneId.systemDefault())
> .toInstant())
> .check();
> // Expected: 1992-01-17T22:30:00.123Z
> // Actual: 1992-01-17T22:30:00Z
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-21867: Assignee: Alexander Lapin > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21768) Wrong key column serialization in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831857#comment-17831857 ] Pavel Tupitsyn commented on IGNITE-21768: - Merged to main: c662f45bbe5c89626f1d6739afbf1198c286e1bb > Wrong key column serialization in ClientKeyValueView > > > Key: IGNITE-21768 > URL: https://issues.apache.org/jira/browse/IGNITE-21768 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ItTablePutGetThinWithMarshaller.java > > Time Spent: 20m > Remaining Estimate: 0h > > *ClientKeyValueView.writeKeyValueRaw* was not updated as part of IGNITE-21525 > changes and still uses key-first order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21864) Provide cluster name in thin client
[ https://issues.apache.org/jira/browse/IGNITE-21864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831853#comment-17831853 ] Mikhail Pochatkin commented on IGNITE-21864: Merged to main: a4dac8ef738a9000bd24d50fb356333e3c6898f1 > Provide cluster name in thin client > --- > > Key: IGNITE-21864 > URL: https://issues.apache.org/jira/browse/IGNITE-21864 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Some clients could benefit from knowing cluster name, we already have it > received in the handshake process, let's provide it in the internal API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21864) Provide cluster name in thin client
[ https://issues.apache.org/jira/browse/IGNITE-21864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-21864. Resolution: Fixed > Provide cluster name in thin client > --- > > Key: IGNITE-21864 > URL: https://issues.apache.org/jira/browse/IGNITE-21864 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Some clients could benefit from knowing cluster name, we already have it > received in the handshake process, let's provide it in the internal API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21768) Wrong key column serialization in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831841#comment-17831841 ] Igor Sapego commented on IGNITE-21768: -- Looks good to me. > Wrong key column serialization in ClientKeyValueView > > > Key: IGNITE-21768 > URL: https://issues.apache.org/jira/browse/IGNITE-21768 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ItTablePutGetThinWithMarshaller.java > > Time Spent: 10m > Remaining Estimate: 0h > > *ClientKeyValueView.writeKeyValueRaw* was not updated as part of IGNITE-21525 > changes and still uses key-first order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Fix Version/s: 3.0.0-beta2
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21872) Implement IgniteSql#executeBatchAsync() accepting Statement
[ https://issues.apache.org/jira/browse/IGNITE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21872: --- Summary: Implement IgniteSql#executeBatchAsync() accepting Statement (was: Implement IgniteSql#executeBatchAsync()) > Implement IgniteSql#executeBatchAsync() accepting Statement > --- > > Key: IGNITE-21872 > URL: https://issues.apache.org/jira/browse/IGNITE-21872 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > The method is not implemented now, it just throws > UnsupportedOperationException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21872) Implement IgniteSql#executeBatchAsync()
Roman Puchkovskiy created IGNITE-21872: -- Summary: Implement IgniteSql#executeBatchAsync() Key: IGNITE-21872 URL: https://issues.apache.org/jira/browse/IGNITE-21872 Project: Ignite Issue Type: Improvement Components: sql Reporter: Roman Puchkovskiy The method is not implemented now, it just throws UnsupportedOperationException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21223) Add xml example WAL Records Compression
[ https://issues.apache.org/jira/browse/IGNITE-21223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831833#comment-17831833 ] Aleksandr Nikolaev edited comment on IGNITE-21223 at 3/28/24 2:25 PM: -- [~andreinadyktov] looks good !walcompress.png|width=931,height=339! was (Author: aonikolaev): [~andreinadyktov] looks good !walcompress.png! > Add xml example WAL Records Compression > > > Key: IGNITE-21223 > URL: https://issues.apache.org/jira/browse/IGNITE-21223 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Major > Labels: ise, newbee > Attachments: walcompress.png > > Time Spent: 10m > Remaining Estimate: 0h > > Add xml example WAL Records Compression > [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21223) Add xml example WAL Records Compression
[ https://issues.apache.org/jira/browse/IGNITE-21223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21223: Attachment: walcompress.png > Add xml example WAL Records Compression > > > Key: IGNITE-21223 > URL: https://issues.apache.org/jira/browse/IGNITE-21223 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Major > Labels: ise, newbee > Attachments: walcompress.png > > Time Spent: 10m > Remaining Estimate: 0h > > Add xml example WAL Records Compression > [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21223) Add xml example WAL Records Compression
[ https://issues.apache.org/jira/browse/IGNITE-21223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831833#comment-17831833 ] Aleksandr Nikolaev commented on IGNITE-21223: - [~andreinadyktov] looks good !walcompress.png! > Add xml example WAL Records Compression > > > Key: IGNITE-21223 > URL: https://issues.apache.org/jira/browse/IGNITE-21223 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Major > Labels: ise, newbee > Attachments: walcompress.png > > Time Spent: 10m > Remaining Estimate: 0h > > Add xml example WAL Records Compression > [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Labels: ignite-3 (was: )
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21871) SharedRocksDbInstance#sortedIndexes method is not thread-safe
Aleksandr Polovtcev created IGNITE-21871:
Summary: SharedRocksDbInstance#sortedIndexes method is not
thread-safe
Key: IGNITE-21871
URL: https://issues.apache.org/jira/browse/IGNITE-21871
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
It is possible to obtain a {{ConcurrentModificationException}} when calling
{{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
Aleksandr Polovtcev created IGNITE-21870:
Summary: SharedRocksDbInstance#sortedIndexes method is not
thread-safe
Key: IGNITE-21870
URL: https://issues.apache.org/jira/browse/IGNITE-21870
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
It is possible to obtain a {{ConcurrentModificationException}} when calling
{{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21131) Calcite engine. OR operator with dynamic parameters can't be used for index scans
[
https://issues.apache.org/jira/browse/IGNITE-21131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21131:
--
Labels: calcite ise (was: calcite calcite3-required ise)
> Calcite engine. OR operator with dynamic parameters can't be used for index
> scans
> -
>
> Key: IGNITE-21131
> URL: https://issues.apache.org/jira/browse/IGNITE-21131
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calcite can compose OR operator with literals to SEARCH/SARG, and SEARCH/SARG
> can be used for index scans. But we can't do this for OR operator with
> dynamic parameters.
> For example expression {{a IN (1, 2, 3)}} can be converted to {{a = 1 OR a =
> 2 OR a = 3}} and after that can be converted to {{SEARCH(a, SARG(1, 2, 3))}},
> but expression {{a IN (?, ?, ?)}} can be converted only to {{a = ? OR a = ?
> OR a = ?}} and can't be used for index scan.
> To fix this issue we can create ranges from dynamic parameters during
> planning, sort and remove intersections from these ranges in runtime.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21544) Amend SQL related thread pools.
[ https://issues.apache.org/jira/browse/IGNITE-21544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-21544. --- Resolution: Won't Do Fixed in IGNITE-21669 > Amend SQL related thread pools. > > > Key: IGNITE-21544 > URL: https://issues.apache.org/jira/browse/IGNITE-21544 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now SQL module have 3 thread-pools. In order to minimize number of > threads/threadspool let's get rid of sql-session-cleanup threadpool . The > works by cleanup sessions can be delegated to > ThreadPoolsManager.commonScheduler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21869) Prevent thread hijacking via IgniteSql
[ https://issues.apache.org/jira/browse/IGNITE-21869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21869: --- Description: Methods of IgniteSql that return CompletableFutures must wrap their return value with PublicApiThreading#preventThreadHijack(). Also, tests need to be created (similar to ItKvRecordApiThreadingTest). (was: Methods of IgniteTransactions that return CompletableFutures must wrap their return value with PublicApiThreading#preventThreadHijack(). Also, tests need to be created (similar to ItKvRecordApiThreadingTest).) > Prevent thread hijacking via IgniteSql > -- > > Key: IGNITE-21869 > URL: https://issues.apache.org/jira/browse/IGNITE-21869 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, threading > > Methods of IgniteSql that return CompletableFutures must wrap their return > value with PublicApiThreading#preventThreadHijack(). Also, tests need to be > created (similar to ItKvRecordApiThreadingTest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21869) Prevent thread hijacking via IgniteSql
Roman Puchkovskiy created IGNITE-21869: -- Summary: Prevent thread hijacking via IgniteSql Key: IGNITE-21869 URL: https://issues.apache.org/jira/browse/IGNITE-21869 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Methods of IgniteTransactions that return CompletableFutures must wrap their return value with PublicApiThreading#preventThreadHijack(). Also, tests need to be created (similar to ItKvRecordApiThreadingTest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Description: h3. Motivation RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but actually it's a business operation one. Within the context of replicaService, there are legitimate reasons for operation to be processed longer than current timeout of 3 seconds, basically it should be possible to wait indefinitely until the transaction times out. But because we don't have transaction timeout and because of possible bugs it seems reasonable to have an operation processing timeout "watchdog" with finite but relatively big configurable value. h3. Definition of Done * Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values was: h3. Motivation RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but actually it's a business operation one. Within the context of replicaService, there are legitimate reasons for operation to be processed longer than current timeout of 3 seconds, basically it should be possible to wait indefinitely until the transaction times out. But because we don't have transaction timeout and because of possible bugs it seems reasonable to have an operation processing timeout "watchdog" with finite but relatively big configurable value. h3. Definition of Done > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Epic Link: IGNITE-21389 > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Description: h3. Motivation RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but actually it's a business operation one. Within the context of replicaService, there are legitimate reasons for operation to be processed longer than current timeout of 3 seconds, basically it should be possible to wait indefinitely until the transaction times out. But because we don't have transaction timeout and because of possible bugs it seems reasonable to have an operation processing timeout "watchdog" with finite but relatively big configurable value. h3. Definition of Done was: h3. Motivation RPC_TIMEOUT is actually but a business operation timeout, thus it should be configured separately depending on the operation type. > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Labels: ignite-3 (was: ) > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > RPC_TIMEOUT was mistakenly recognized as a network layer timeout, but > actually it's a business operation one. Within the context of replicaService, > there are legitimate reasons for operation to be processed longer than > current timeout of 3 seconds, basically it should be possible to wait > indefinitely until the transaction times out. But because we don't have > transaction timeout and because of possible bugs it seems reasonable to have > an operation processing timeout "watchdog" with finite but relatively big > configurable value. > h3. Definition of Done > * Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21382) Test ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21382:
--
Reviewer: Vladislav Pyatkov
> Test ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling is flaky
> --
>
> Key: IGNITE-21382
> URL: https://issues.apache.org/jira/browse/IGNITE-21382
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The test falls while waiting for the primary replica change. This issue is
> also reproduced locally, at least one per five passes.
> {code}
> assertThat(primaryChangeTask, willCompleteSuccessfully());
> {code}
> {noformat}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.placementdriver.ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling(ItPrimaryReplicaChoiceTest.java:179)
> {noformat}
> This test will be muted on TC to pervent future falls.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21763) Adjust TxnResourceVacuumTask in order to vacuum persistent txn state
[
https://issues.apache.org/jira/browse/IGNITE-21763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-21763:
-
Assignee: Denis Chudov (was: Alexander Lapin)
> Adjust TxnResourceVacuumTask in order to vacuum persistent txn state
>
>
> Key: IGNITE-21763
> URL: https://issues.apache.org/jira/browse/IGNITE-21763
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> h3. Definition of Done
> * TxnResourceVacuumTask is adjusted in a way that
> ** txnState is removed from txnStateVolatileMap if
> {*}max{*}(cleanupCompletionTimestamp, initialVacuumObservationTimestamp) +
> txnResourcesTTL < vacuumObservationTimestamp
> ** If there's a value in cleanupCompletionTimestamp, prior to removal the
> txnState from the volatile map it's required to remove corresponding record
> from within txn persistant state storage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21808) CREATE ZONE syntax must work with any the case of zone name
[
https://issues.apache.org/jira/browse/IGNITE-21808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831788#comment-17831788
]
Mikhail Efremov commented on IGNITE-21808:
--
[~korlov] could you take a look too?
> CREATE ZONE syntax must work with any the case of zone name
> ---
>
> Key: IGNITE-21808
> URL: https://issues.apache.org/jira/browse/IGNITE-21808
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Steps to reproduce
> If we try to run such code
> {code:java}
> cluster.doInSession(0, session -> {
> session.execute(null, "CREATE ZONE test_zone");
> session.execute(null, "CREATE TABLE TEST (id INT PRIMARY KEY,
> name INT) WITH PRIMARY_ZONE='test_zone'");
> });
> {code}
> It fails with {{Failed to validate query. Distribution zone with name
> 'test_zone' not found,}}
> but works if zone name is in upper case
> This behaviour must be changed.
> h3. Definition of done
> * Zone name must support any case, not only upper case
> * Corresponding tests must be added
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21868) Move the sql RO inflights handling from SqlQueryProcessor to QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit
Denis Chudov created IGNITE-21868: - Summary: Move the sql RO inflights handling from SqlQueryProcessor to QueryTransactionContext#getOrStartImplicit/QueryTransactionWrapper#commitImplicit Key: IGNITE-21868 URL: https://issues.apache.org/jira/browse/IGNITE-21868 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Assignee: Denis Chudov * -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
[ https://issues.apache.org/jira/browse/IGNITE-21867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21867: - Description: h3. Motivation RPC_TIMEOUT is actually but a business operation timeout, thus it should be configured separately depending on the operation type. > Add ability to configure ReplicaService#RPC_TIMEOUT and > TxMessageSender#RPC_TIMEOUT and increase the default values > --- > > Key: IGNITE-21867 > URL: https://issues.apache.org/jira/browse/IGNITE-21867 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > RPC_TIMEOUT is actually but a business operation timeout, thus it should be > configured separately depending on the operation type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21867) Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values
Alexander Lapin created IGNITE-21867: Summary: Add ability to configure ReplicaService#RPC_TIMEOUT and TxMessageSender#RPC_TIMEOUT and increase the default values Key: IGNITE-21867 URL: https://issues.apache.org/jira/browse/IGNITE-21867 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21862) Rename table catalog command must also rename the PK index
[
https://issues.apache.org/jira/browse/IGNITE-21862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21862:
-
Description: {{RenameTableCommand}} is used to rename a table. However, it
does not rename its primary key, which is tied to the table's name. This leads
to a bug, for example, when you rename a table and create a new table with the
old name an exception is thrown indicating that an index with this name already
exists.
> Rename table catalog command must also rename the PK index
> --
>
> Key: IGNITE-21862
> URL: https://issues.apache.org/jira/browse/IGNITE-21862
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> {{RenameTableCommand}} is used to rename a table. However, it does not rename
> its primary key, which is tied to the table's name. This leads to a bug, for
> example, when you rename a table and create a new table with the old name an
> exception is thrown indicating that an index with this name already exists.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[
https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831771#comment-17831771
]
Alexander Belyak commented on IGNITE-20731:
---
[~slava.koptilin] I'm unable to reproduce it on a fresh main branch.
> Exception "The primary replica has changed" on big amount of rows
> -
>
> Key: IGNITE-20731
> URL: https://issues.apache.org/jira/browse/IGNITE-20731
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m"
> 2. Execute
> {code:java}
> create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50)
> not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null,
> column_4 VARCHAR(50) not null, primary key (id)) {code}
> 3. Insert rows into table up to 1 000 000 rows.
> *Expected result:*
> Rows are inserted.
> *Actual result:*
> After 733000 rows the exception is thrown.
> Client:
> {code:java}
> java.sql.BatchUpdateException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155)
> {code}
> Server:
> {code:java}
> 2023-10-23 13:47:31:529 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_12]
> 2023-10-23 13:47:31:532 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_20]
> 2023-10-23 13:47:31:536 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_24]
> 2023-10-23 13:47:31:539 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_16]
> 2023-10-23 13:47:31:699 +0300
> [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24,
> groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0,
> 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9,
> 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22,
> 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24],
> term=111283839559532593, timestampLong=111283932466315264,
> txId=018b5c25-7653---23c06ab5]]
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281)
> at
>
[jira] [Resolved] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[
https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak resolved IGNITE-20731.
---
Resolution: Cannot Reproduce
> Exception "The primary replica has changed" on big amount of rows
> -
>
> Key: IGNITE-20731
> URL: https://issues.apache.org/jira/browse/IGNITE-20731
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m"
> 2. Execute
> {code:java}
> create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50)
> not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null,
> column_4 VARCHAR(50) not null, primary key (id)) {code}
> 3. Insert rows into table up to 1 000 000 rows.
> *Expected result:*
> Rows are inserted.
> *Actual result:*
> After 733000 rows the exception is thrown.
> Client:
> {code:java}
> java.sql.BatchUpdateException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155)
> {code}
> Server:
> {code:java}
> 2023-10-23 13:47:31:529 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_12]
> 2023-10-23 13:47:31:532 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_20]
> 2023-10-23 13:47:31:536 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_24]
> 2023-10-23 13:47:31:539 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_16]
> 2023-10-23 13:47:31:699 +0300
> [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24,
> groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0,
> 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9,
> 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22,
> 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24],
> term=111283839559532593, timestampLong=111283932466315264,
> txId=018b5c25-7653---23c06ab5]]
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281)
> at
>
[jira] [Commented] (IGNITE-21864) Provide cluster name in thin client
[ https://issues.apache.org/jira/browse/IGNITE-21864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831765#comment-17831765 ] Pavel Tupitsyn commented on IGNITE-21864: - [~vpakhnushev] looks good to me. > Provide cluster name in thin client > --- > > Key: IGNITE-21864 > URL: https://issues.apache.org/jira/browse/IGNITE-21864 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Some clients could benefit from knowing cluster name, we already have it > received in the handshake process, let's provide it in the internal API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21864) Provide cluster name in thin client
[ https://issues.apache.org/jira/browse/IGNITE-21864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21864: Fix Version/s: 3.0.0-beta2 > Provide cluster name in thin client > --- > > Key: IGNITE-21864 > URL: https://issues.apache.org/jira/browse/IGNITE-21864 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Some clients could benefit from knowing cluster name, we already have it > received in the handshake process, let's provide it in the internal API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21866) Calcite engine. Add memory quotas control for Cursor.getAll() method
Aleksey Plekhanov created IGNITE-21866: -- Summary: Calcite engine. Add memory quotas control for Cursor.getAll() method Key: IGNITE-21866 URL: https://issues.apache.org/jira/browse/IGNITE-21866 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Cursor.getAll() method can collect a lot of rows before return result to the user and can cause OOM errors. We should control memory consumption for Cursor.getAll() the same way as we do for execution nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21865) [PerfStat] Add metadata about tables, columns, indexes
[
https://issues.apache.org/jira/browse/IGNITE-21865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-21865:
-
Labels: ise (was: )
> [PerfStat] Add metadata about tables, columns, indexes
> --
>
> Key: IGNITE-21865
> URL: https://issues.apache.org/jira/browse/IGNITE-21865
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
>
> The PerfStat report contains information about which SQL queries were
> executed and what their execution plan was. But there is no information about
> what tables are in the cluster, what columns are in the tables, what indexes
> are created.
> In our case, we had to request additional information about tables and
> indexes to understand the cause of the problematic query plan. Used:
> {code:java}
> ./control.sh --system-view TABLES
> ./control.sh --system-view TABLES_COLUMNS
> ./control.sh --system-view INDEXES
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21864) Provide cluster name in thin client
Vadim Pakhnushev created IGNITE-21864: - Summary: Provide cluster name in thin client Key: IGNITE-21864 URL: https://issues.apache.org/jira/browse/IGNITE-21864 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev Some clients could benefit from knowing cluster name, we already have it received in the handshake process, let's provide it in the internal API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21865) [PerfStat] Add metadata about tables, columns, indexes
Luchnikov Alexander created IGNITE-21865:
Summary: [PerfStat] Add metadata about tables, columns, indexes
Key: IGNITE-21865
URL: https://issues.apache.org/jira/browse/IGNITE-21865
Project: Ignite
Issue Type: Improvement
Reporter: Luchnikov Alexander
The PerfStat report contains information about which SQL queries were executed
and what their execution plan was. But there is no information about what
tables are in the cluster, what columns are in the tables, what indexes are
created.
In our case, we had to request additional information about tables and indexes
to understand the cause of the problematic query plan. Used:
{code:java}
./control.sh --system-view TABLES
./control.sh --system-view TABLES_COLUMNS
./control.sh --system-view INDEXES
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21820) Sql. Test framework. Activate indices created via TestNode::initSchema script.
[ https://issues.apache.org/jira/browse/IGNITE-21820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-21820: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Test framework. Activate indices created via TestNode::initSchema script. > -- > > Key: IGNITE-21820 > URL: https://issues.apache.org/jira/browse/IGNITE-21820 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > We should activate indices defined in init script, otherwise execution of > this script hangs indefinitely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21863) [PerfStat] OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-21863:
-
Summary: [PerfStat] OOM when using build-report.sh from performance
statistics (was: OOM when using build-report.sh from performance statistics)
> [PerfStat] OOM when using build-report.sh from performance statistics
> --
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
>
> The problem is reproduced on a large volume collected using
> {code:java}
> ./control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21863) OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-21863:
-
Labels: ise (was: )
> OOM when using build-report.sh from performance statistics
> ---
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
>
> The problem is reproduced on a large volume collected using
> {code:java}
> ./control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21863) OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-21863:
-
Description:
The problem is reproduced on a large volume collected using
{code:java}
./control.sh --performance-statistics
{code}
statistics, in our cases the total volume was 50GB.
Increasing xmx to 64gb did not solve the problem.
{code:java}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.HashMap.resize(HashMap.java:700)
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
at
org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
{code}
was:
The problem is reproduced on a large volume collected using
{code:java}
control.sh --performance-statistics
{code}
statistics, in our cases the total volume was 50GB.
Increasing xmx to 64gb did not solve the problem.
{code:java}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.HashMap.resize(HashMap.java:700)
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
at
org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
{code}
> OOM when using build-report.sh from performance statistics
> ---
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Priority: Minor
>
> The problem is reproduced on a large volume collected using
> {code:java}
> ./control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21863) OOM when using build-report.sh from performance statistics
Luchnikov Alexander created IGNITE-21863:
Summary: OOM when using build-report.sh from performance
statistics
Key: IGNITE-21863
URL: https://issues.apache.org/jira/browse/IGNITE-21863
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.16
Reporter: Luchnikov Alexander
The problem is reproduced on a large volume collected using
{code:java}
control.sh --performance-statistics
{code}
statistics, in our cases the total volume was 50GB.
Increasing xmx to 64gb did not solve the problem.
{code:java}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.HashMap.resize(HashMap.java:700)
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
at
org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
at
org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
at
org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21863) OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luchnikov Alexander updated IGNITE-21863:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> OOM when using build-report.sh from performance statistics
> ---
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Priority: Minor
>
> The problem is reproduced on a large volume collected using
> {code:java}
> control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21684) Sql. Exception from a scan operation is not correctly propagated if OrderedPublisher is used.
[
https://issues.apache.org/jira/browse/IGNITE-21684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov resolved IGNITE-21684.
---
Resolution: Fixed
Was fixed in IGNITE-20126
> Sql. Exception from a scan operation is not correctly propagated if
> OrderedPublisher is used.
> -
>
> Key: IGNITE-21684
> URL: https://issues.apache.org/jira/browse/IGNITE-21684
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Konstantin Orlov
>Priority: Minor
> Labels: ignite-3
>
> The root cause of an exception thrown from an sorted index scan operation is
> lost.
> Reproducer can be found in
> ItSchemaSyncSingleNodeTest::readWriteOperationAfterDroppingTargetTableIsRejected
> (change a primary key index to a sorted one get such error).
> {code:java}
> java.lang.AssertionError:
> Expected: a string containing "Table was dropped [table=6]"
> but: was null
> Expected :a string containing "Table was dropped [table=6]"
> Actual :null
> {code}
> Although a stack trace on a server includes that error:
> {code:java}
> Suppressed: java.util.concurrent.CompletionException:
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
> IGN-TX-12 TraceId:68590499-47c7-46a9-bd5a-d75f2090aebc Table was dropped
> [table=6]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21684) Sql. Exception from a scan operation is not correctly propagated if OrderedPublisher is used.
[
https://issues.apache.org/jira/browse/IGNITE-21684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21684:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Exception from a scan operation is not correctly propagated if
> OrderedPublisher is used.
> -
>
> Key: IGNITE-21684
> URL: https://issues.apache.org/jira/browse/IGNITE-21684
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Konstantin Orlov
>Priority: Minor
> Labels: ignite-3
>
> The root cause of an exception thrown from an sorted index scan operation is
> lost.
> Reproducer can be found in
> ItSchemaSyncSingleNodeTest::readWriteOperationAfterDroppingTargetTableIsRejected
> (change a primary key index to a sorted one get such error).
> {code:java}
> java.lang.AssertionError:
> Expected: a string containing "Table was dropped [table=6]"
> but: was null
> Expected :a string containing "Table was dropped [table=6]"
> Actual :null
> {code}
> Although a stack trace on a server includes that error:
> {code:java}
> Suppressed: java.util.concurrent.CompletionException:
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
> IGN-TX-12 TraceId:68590499-47c7-46a9-bd5a-d75f2090aebc Table was dropped
> [table=6]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21862) Rename table catalog command must also rename the PK index
Aleksandr Polovtcev created IGNITE-21862: Summary: Rename table catalog command must also rename the PK index Key: IGNITE-21862 URL: https://issues.apache.org/jira/browse/IGNITE-21862 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21849) Prevent thread hijacking via IgniteTables
[ https://issues.apache.org/jira/browse/IGNITE-21849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831731#comment-17831731 ] Roman Puchkovskiy commented on IGNITE-21849: Thanks > Prevent thread hijacking via IgniteTables > - > > Key: IGNITE-21849 > URL: https://issues.apache.org/jira/browse/IGNITE-21849 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, threading > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Methods of IgniteTables that return CompletableFutures must wrap their return > value with PublicApiThreading#preventThreadHijack(). Also, tests need to be > created (similar to ItKvRecordApiThreadingTest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18590) Transaction recovery tries rollback a tx concurrently with committing it
[ https://issues.apache.org/jira/browse/IGNITE-18590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-18590: --- Labels: ise (was: ) > Transaction recovery tries rollback a tx concurrently with committing it > > > Key: IGNITE-18590 > URL: https://issues.apache.org/jira/browse/IGNITE-18590 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a bug introduced in the patch > [https://github.com/apache/ignite/pull/8822.] > When a transaction commits on primary node during TxRecovery procedure, it > also sends rollback request (GridDhtTxFinishRequest#commit = false) on backup > nodes. > Then it's possible that such a request (commit = false) reaches a backup node > earlier than GridCacheTxRecoveryResponse(commit = true). Then primary node > will commit the transaction, and backup node rollbacks it. Then cluster will > be in inconsistent state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--
Fix Version/s: 3.0.0-beta2
> Sql. Index is not used for IN predicate with column type of UUID
>
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('--0001--0001'::UUID,
> '--0003--0001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h4. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21722) Sql. NPE in correlated nested loop join
[
https://issues.apache.org/jira/browse/IGNITE-21722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21722:
--
Description:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
*Update*
The following sequence occurs:
# {{CorrelatedNestedLoopJoinNode}} pushes last row to downstream (FilterNode).
See {{joinType == JoinRelType.LEFT}} branch in {{join()}} method.
# {{FilterNode}} receives last requested row and tries to request next batch
from the upstream ({{CorrelatedNestedLoopJoinNode}}).
# {{CorrelatedNestedLoopJoinNode}} is in {{IDLE}} state (which is incorrect),
so it submits {{join()}} to the execution queue.
# {{CorrelatedNestedLoopJoinNode}} resets {{rightInBuf}}, changes state to
{{FILLING_LEFT}} and requests rows from {{leftsource()}}.
# Previously submitted {{join()}} starts executing and crashes with
{{NullPointerException}}, because {{rightInBuf}} is null.
was:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
*Update*
The following sequence occurs:
# {{CorrelatedNestedLoopJoinNode}} pushes last row to downstream (FilterNode).
See {{joinType == JoinRelType.LEFT}} branch in {{join()}} method.
# {{FilterNode}} receives last requested row and tries to request next batch
from the upstream ({{CorrelatedNestedLoopJoinNode}}).
# {{CorrelatedNestedLoopJoinNode is in {{IDLE}} state (which is incorrect), so
it submits {{join()}} to the execution queue.
# {{CorrelatedNestedLoopJoinNode}} resets {{rightInBuf}}, changes state to
{{FILLING_LEFT}} and requests rows from {{leftsource()}}.
# Previously submitted {{join()}} starts executing and crashes with
{{NullPointerException}}, because {{rightInBuf}} is null.
> Sql. NPE in correlated nested loop join
> ---
>
> Key: IGNITE-21722
> URL: https://issues.apache.org/jira/browse/IGNITE-21722
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: calcite2-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See stack trace below:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
> ... 4 more
> {code}
> To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
> *Update*
> The following sequence occurs:
> # {{CorrelatedNestedLoopJoinNode}} pushes last row to downstream
> (FilterNode). See {{joinType == JoinRelType.LEFT}} branch in {{join()}}
> method.
> # {{FilterNode}} receives last requested row and tries to request next batch
> from the upstream ({{CorrelatedNestedLoopJoinNode}}).
> # {{CorrelatedNestedLoopJoinNode}} is in {{IDLE}} state (which is
> incorrect), so it submits {{join()}} to the execution queue.
> # {{CorrelatedNestedLoopJoinNode}} resets {{rightInBuf}}, changes state to
> {{FILLING_LEFT}} and requests rows from {{leftsource()}}.
> # Previously submitted {{join()}} starts executing and crashes with
> {{NullPointerException}}, because {{rightInBuf}} is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21722) Sql. NPE in correlated nested loop join
[
https://issues.apache.org/jira/browse/IGNITE-21722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21722:
--
Description:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
*Update*
The following sequence occurs:
# {{CorrelatedNestedLoopJoinNode}} pushes last row to downstream (FilterNode).
See {{joinType == JoinRelType.LEFT}} branch in {{join()}} method.
# {{FilterNode}} receives last requested row and tries to request next batch
from the upstream ({{CorrelatedNestedLoopJoinNode}}).
# {{CorrelatedNestedLoopJoinNode is in {{IDLE}} state (which is incorrect), so
it submits {{join()}} to the execution queue.
# {{CorrelatedNestedLoopJoinNode}} resets {{rightInBuf}}, changes state to
{{FILLING_LEFT}} and requests rows from {{leftsource()}}.
# Previously submitted {{join()}} starts executing and crashes with
{{NullPointerException}}, because {{rightInBuf}} is null.
was:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
*Update*
The following sequence occurs:
CorrelatedNestedLoopJoinNode pushes last row to downstream (FilterNode).
See joinType == JoinRelType.LEFT branch in join() method.
FilterNode receives last requested row and tries to request next batch from
the upstream (CorrelatedNestedLoopJoinNode).
CorrelatedNestedLoopJoinNode is in IDLE state (which is incorrect), so it
submits join() to the execution queue.
CorrelatedNestedLoopJoinNode resets rightInBuf, changes state to
FILLING_LEFT and requests rows from leftsource().
Previously submitted join() starts executing and crashes with
NullPointerException, because rightInBuf is null.
> Sql. NPE in correlated nested loop join
> ---
>
> Key: IGNITE-21722
> URL: https://issues.apache.org/jira/browse/IGNITE-21722
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: calcite2-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See stack trace below:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
> ... 4 more
> {code}
> To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
> *Update*
> The following sequence occurs:
> # {{CorrelatedNestedLoopJoinNode}} pushes last row to downstream
> (FilterNode). See {{joinType == JoinRelType.LEFT}} branch in {{join()}}
> method.
> # {{FilterNode}} receives last requested row and tries to request next batch
> from the upstream ({{CorrelatedNestedLoopJoinNode}}).
> # {{CorrelatedNestedLoopJoinNode is in {{IDLE}} state (which is incorrect),
> so it submits {{join()}} to the execution queue.
> # {{CorrelatedNestedLoopJoinNode}} resets {{rightInBuf}}, changes state to
> {{FILLING_LEFT}} and requests rows from {{leftsource()}}.
> # Previously submitted {{join()}} starts executing and crashes with
> {{NullPointerException}}, because {{rightInBuf}} is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21722) Sql. NPE in correlated nested loop join
[
https://issues.apache.org/jira/browse/IGNITE-21722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21722:
--
Description:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
*Update*
The following sequence occurs:
CorrelatedNestedLoopJoinNode pushes last row to downstream (FilterNode).
See joinType == JoinRelType.LEFT branch in join() method.
FilterNode receives last requested row and tries to request next batch from
the upstream (CorrelatedNestedLoopJoinNode).
CorrelatedNestedLoopJoinNode is in IDLE state (which is incorrect), so it
submits join() to the execution queue.
CorrelatedNestedLoopJoinNode resets rightInBuf, changes state to
FILLING_LEFT and requests rows from leftsource().
Previously submitted join() starts executing and crashes with
NullPointerException, because rightInBuf is null.
was:
See stack trace below:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
at
org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
... 4 more
{code}
To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
> Sql. NPE in correlated nested loop join
> ---
>
> Key: IGNITE-21722
> URL: https://issues.apache.org/jira/browse/IGNITE-21722
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: calcite2-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See stack trace below:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
> ... 4 more
> {code}
> To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
> *Update*
> The following sequence occurs:
> CorrelatedNestedLoopJoinNode pushes last row to downstream (FilterNode).
> See joinType == JoinRelType.LEFT branch in join() method.
> FilterNode receives last requested row and tries to request next batch
> from the upstream (CorrelatedNestedLoopJoinNode).
> CorrelatedNestedLoopJoinNode is in IDLE state (which is incorrect), so it
> submits join() to the execution queue.
> CorrelatedNestedLoopJoinNode resets rightInBuf, changes state to
> FILLING_LEFT and requests rows from leftsource().
> Previously submitted join() starts executing and crashes with
> NullPointerException, because rightInBuf is null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20782) Ignite 3.0: Dynamically created indexes integration and improvements
[ https://issues.apache.org/jira/browse/IGNITE-20782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin resolved IGNITE-20782. -- Resolution: Fixed > Ignite 3.0: Dynamically created indexes integration and improvements > > > Key: IGNITE-20782 > URL: https://issues.apache.org/jira/browse/IGNITE-20782 > Project: Ignite > Issue Type: Epic > Components: persistence >Reporter: Sergey Chugunov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Description:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
... 10 more{code}
It happens in PartitionReplicaListener because the local volatile tx state is
null or final when trying to compute a value for txCleanupReadyFutures map:
{code:java}
txCleanupReadyFutures.compute(txId, (id, txOps) -> {
// First check whether the transaction has already been finished.
// And complete cleanupReadyFut with exception if it is the case.
TxStateMeta txStateMeta = txManager.stateMeta(txId);
if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
cleanupReadyFut.completeExceptionally(new Exception());
return txOps;
}
// Otherwise collect cleanupReadyFut in the transaction's futures.
if (txOps == null) {
txOps = new TxCleanupReadyFutureList();
}
txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
cleanupReadyFut);
return txOps;
});
if (cleanupReadyFut.isCompletedExceptionally()) {
return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
"Transaction is already finished."));
}{code}
First problem is that we don't actually know the real state from this exception.
The second one is the exception itself, because it shouldn't happen. We
shouldn't meet a null state, because it's updated to pending just before, and
it can be vacuumized only after it becomes final.
Committed state is also not possible because we wait for all in-flights before
the state transition. It can be Aborted state here, but there should be no
exception in logs in this case.
In our case, the transaction is most likely aborted because of replication
timeout exception happened before (it would be nice to see a tx id in this
exception as well).
Full log is attached.
*Defitinion of done:*
* no TransactionException in log in case of aborted
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Description:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
... 10 more{code}
It happens in PartitionReplicaListener because the local volatile tx state is
null or final when trying to compute a value for txCleanupReadyFutures map:
{code:java}
txCleanupReadyFutures.compute(txId, (id, txOps) -> {
// First check whether the transaction has already been finished.
// And complete cleanupReadyFut with exception if it is the case.
TxStateMeta txStateMeta = txManager.stateMeta(txId);
if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
cleanupReadyFut.completeExceptionally(new Exception());
return txOps;
}
// Otherwise collect cleanupReadyFut in the transaction's futures.
if (txOps == null) {
txOps = new TxCleanupReadyFutureList();
}
txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
cleanupReadyFut);
return txOps;
});
if (cleanupReadyFut.isCompletedExceptionally()) {
return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
"Transaction is already finished."));
}{code}
First problem is that we don't actually know the real state from this exception.
The second one is the exception itself, because it shouldn't happen. We
shouldn't meet a null state, because it's updated to pending just before, and
it can be vacuumized only after it becomes final.
Committed state is also not possible because we wait for all in-flights before
the state transition. It can be Aborted state here, but there should be no
exception in logs in this case.
In our case, the transaction is most likely aborted because of replication
timeout exception happened before (it would be nice to see a tx id in this
exception as well).
Full log is attached.
*Defitinion of done:*
* no TransactionException in log in case of aborted
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Description:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
... 10 more{code}
It happens in PartitionReplicaListener because the local volatile tx state is
null or final when trying to compute a value for txCleanupReadyFutures map:
{code:java}
txCleanupReadyFutures.compute(txId, (id, txOps) -> {
// First check whether the transaction has already been finished.
// And complete cleanupReadyFut with exception if it is the case.
TxStateMeta txStateMeta = txManager.stateMeta(txId);
if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
cleanupReadyFut.completeExceptionally(new Exception());
return txOps;
}
// Otherwise collect cleanupReadyFut in the transaction's futures.
if (txOps == null) {
txOps = new TxCleanupReadyFutureList();
}
txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
cleanupReadyFut);
return txOps;
});
if (cleanupReadyFut.isCompletedExceptionally()) {
return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
"Transaction is already finished."));
}{code}
First problem is that we don't actually know the real state from this exception.
The second one is the exception itself, because it shouldn't happen. We
shouldn't meet a null state, because it's updated to pending just before, and
it can be vacuumized only after it becomes final.
Committed state is also not possible because we wait for all in-flights before
the state transition. It can be Aborted state here, but there should be no
exception in logs in this case.
In our case, the transaction is most likely aborted because of replication
timeout exception happened before (it would be nice to see a tx id in this
exception as well).
Full log is attached.
*Defitinion of done:*
* no TransactionException in log in case of aborted
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Attachment: _Integration_Tests_Module_SQL_Engine_4133_.log
> Unexpected "Transaction is already finished" exception
> ---
>
> Key: IGNITE-21861
> URL: https://issues.apache.org/jira/browse/IGNITE-21861
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_SQL_Engine_4133_.log
>
>
> Exception in log:
> {code:java}
> [2024-03-27T01:24:46,636][WARN
> ][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
> request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
> columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
> [partitionId=17, tableId=90],
> coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
> enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
> full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
> scanId=20361, timestampLong=112165039967305730,
> transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
> java.util.concurrent.CompletionException:
> org.apache.ignite.tx.TransactionException: IGN-TX-14
> TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> [?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
> [?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
> [?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
> finished.
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> ... 10 more{code}
> It happens in PartitionReplicaListener because the local volatile tx state is
> null or final when trying to compute a value for txCleanupReadyFutures map:
> {code:java}
> txCleanupReadyFutures.compute(txId, (id, txOps) -> {
> // First check whether the transaction has already been finished.
> // And complete cleanupReadyFut with exception if it is the case.
> TxStateMeta txStateMeta = txManager.stateMeta(txId);
> if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
> cleanupReadyFut.completeExceptionally(new Exception());
> return txOps;
> }
> // Otherwise collect cleanupReadyFut in the transaction's futures.
> if (txOps == null) {
> txOps = new TxCleanupReadyFutureList();
> }
> txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
> cleanupReadyFut);
> return txOps;
> });
> if (cleanupReadyFut.isCompletedExceptionally()) {
> return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
> "Transaction is already finished."));
> }{code}
> First problem is that we don't actually know the real state from this
> exception.
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Description:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
... 10 more{code}
It happens in PartitionReplicaListener because the local volatile tx state is
null or final when trying to compute a value for txCleanupReadyFutures map:
{code:java}
txCleanupReadyFutures.compute(txId, (id, txOps) -> {
// First check whether the transaction has already been finished.
// And complete cleanupReadyFut with exception if it is the case.
TxStateMeta txStateMeta = txManager.stateMeta(txId);
if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
cleanupReadyFut.completeExceptionally(new Exception());
return txOps;
}
// Otherwise collect cleanupReadyFut in the transaction's futures.
if (txOps == null) {
txOps = new TxCleanupReadyFutureList();
}
txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
cleanupReadyFut);
return txOps;
});
if (cleanupReadyFut.isCompletedExceptionally()) {
return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
"Transaction is already finished."));
}{code}
First problem is that we don't actually know the real state from this exception.
The second one is the exception itself, because it shouldn't happen. We
shouldn't meet a null state, because it's updated to pending just before, and
it can be vacuumized only after it becomes final.
Committed state is also not possible because we wait for all in-flights before
the state transition. It can be Aborted state here, but there should be no
exception in logs in this case.
In our case, the transaction is most likely aborted because of replication
timeout exception happened before (it would be nice to see a tx id in this
exception as well).
Full log is attached.
was:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
[jira] [Updated] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[
https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20731:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Exception "The primary replica has changed" on big amount of rows
> -
>
> Key: IGNITE-20731
> URL: https://issues.apache.org/jira/browse/IGNITE-20731
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m"
> 2. Execute
> {code:java}
> create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50)
> not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null,
> column_4 VARCHAR(50) not null, primary key (id)) {code}
> 3. Insert rows into table up to 1 000 000 rows.
> *Expected result:*
> Rows are inserted.
> *Actual result:*
> After 733000 rows the exception is thrown.
> Client:
> {code:java}
> java.sql.BatchUpdateException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155)
> {code}
> Server:
> {code:java}
> 2023-10-23 13:47:31:529 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_12]
> 2023-10-23 13:47:31:532 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_20]
> 2023-10-23 13:47:31:536 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_24]
> 2023-10-23 13:47:31:539 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_16]
> 2023-10-23 13:47:31:699 +0300
> [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24,
> groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0,
> 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9,
> 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22,
> 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24],
> term=111283839559532593, timestampLong=111283932466315264,
> txId=018b5c25-7653---23c06ab5]]
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281)
> at
>
[jira] [Assigned] (IGNITE-21005) Deal with choosing of indexes during garbage collection in MvPartitionStorage
[ https://issues.apache.org/jira/browse/IGNITE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis reassigned IGNITE-21005: -- Assignee: (was: Philipp Shergalis) > Deal with choosing of indexes during garbage collection in MvPartitionStorage > - > > Key: IGNITE-21005 > URL: https://issues.apache.org/jira/browse/IGNITE-21005 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Now, during garbage collection for the repository, for the deleted versions > of rows, we delete them in all indexes known to us. > This is a little inefficient since we may not remove those indexes that will > no longer be accessible to transactions. > We need to deal with this, it does not spoil the consistency of the data, but > it slows down garbage collection. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17591) Refactor toString generation for network messages
[ https://issues.apache.org/jira/browse/IGNITE-17591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis reassigned IGNITE-17591: -- Assignee: Philipp Shergalis > Refactor toString generation for network messages > - > > Key: IGNITE-17591 > URL: https://issues.apache.org/jira/browse/IGNITE-17591 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Semyon Danilov >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > toString method generation for the network message should be taking into > account several things: > 1) Message may contain large objects (such as byte arrays) > 2) Some data can be sensitive, so it should be possible to ignore or mask a > field in the toString method -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21861) Unexpected "Transaction is already finished" exception
[
https://issues.apache.org/jira/browse/IGNITE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21861:
--
Description:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001, upperBoundPrefix=null]].
java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.tx.TransactionException: Transaction is already
finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?]
... 10 more{code}
It happens in PartitionReplicaListener because the local volatile tx state is
null or final when trying to compute a value for txCleanupReadyFutures map:
{code:java}
txCleanupReadyFutures.compute(txId, (id, txOps) -> {
// First check whether the transaction has already been finished.
// And complete cleanupReadyFut with exception if it is the case.
TxStateMeta txStateMeta = txManager.stateMeta(txId);
if (txStateMeta == null || isFinalState(txStateMeta.txState())) {
cleanupReadyFut.completeExceptionally(new Exception());
return txOps;
}
// Otherwise collect cleanupReadyFut in the transaction's futures.
if (txOps == null) {
txOps = new TxCleanupReadyFutureList();
}
txOps.futures.computeIfAbsent(cmdType, type -> new HashMap<>()).put(opId,
cleanupReadyFut);
return txOps;
});
if (cleanupReadyFut.isCompletedExceptionally()) {
return failedFuture(new TransactionException(TX_ALREADY_FINISHED_ERR,
"Transaction is already finished."));
}{code}
First problem is that we don't actually know the real state from this exception.
The second one is the exception itself, because it shouldn't happen. We
shouldn't meet a null state, because it's updated to pending just before, and
it can be vacuumized only after it becomes final.
was:
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false,
[jira] [Created] (IGNITE-21861) Unexpected "Transaction is already finished" exception
Denis Chudov created IGNITE-21861:
-
Summary: Unexpected "Transaction is already finished" exception
Key: IGNITE-21861
URL: https://issues.apache.org/jira/browse/IGNITE-21861
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
Exception in log:
{code:java}
[2024-03-27T01:24:46,636][WARN
][%idt_n_1%partition-operations-4][ReplicaManager] Failed to process replica
request [request=ReadWriteScanRetrieveBatchReplicaRequestImpl [batchSize=512,
columnsToInclude=null, commitPartitionId=TablePartitionIdMessageImpl
[partitionId=17, tableId=90],
coordinatorId=125b397c-0404-4dcf-a28b-625fe010ecef,
enlistmentConsistencyToken=112165039282455690, exactKey=null, flags=0,
full=false, groupId=92_part_7, indexToUse=null, lowerBoundPrefix=null,
scanId=20361, timestampLong=112165039967305730,
transactionId=018e7d82-647b-0030-63a2-6a190001,
upperBoundPrefix=null]].java.util.concurrent.CompletionException:
org.apache.ignite.tx.TransactionException: IGN-TX-14
TraceId:6612dad8-4a32-4453-8af0-0139e336aad9 Transaction is already finished.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?] at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?] at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?] at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:660)
~[ignite-table-3.0.0-SNAPSHOT.jar:?] at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3860)
~[ignite-table-3.0.0-SNAPSHOT.jar:?] at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:436)
~[ignite-table-3.0.0-SNAPSHOT.jar:?] at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?] at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
[?:?] at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
[?:?] at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
[?:?] at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?] at java.base/java.lang.Thread.run(Thread.java:834) [?:?]Caused by:
org.apache.ignite.tx.TransactionException: Transaction is already finished.
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1937)
~[ignite-table-3.0.0-SNAPSHOT.jar:?] at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:659)
~[ignite-table-3.0.0-SNAPSHOT.jar:?] ... 10 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21860) DDL operations hang with "Corrupted LogStorage" message after creating an index
[
https://issues.apache.org/jira/browse/IGNITE-21860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-21860:
Summary: DDL operations hang with "Corrupted LogStorage" message after
creating an index (was: DDL operations hang after creating an index)
> DDL operations hang with "Corrupted LogStorage" message after creating an
> index
> ---
>
> Key: IGNITE-21860
> URL: https://issues.apache.org/jira/browse/IGNITE-21860
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: drop_index_test_ddl.txt, node1.log, node2.log
>
>
> ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
> h1. Setup:
> * 2 server nodes
> h1. Test:
> A set of DDL operations which creates test tables with different field types,
> creates an index over one or more fields and then drops the index. See the
> attached [^drop_index_test_ddl.txt]
> h1. Expected result:
> The test passes
> h1. Actual result:
> The test hangs after executing the following set of operations:
>
> {noformat}
> drop table if exists dropIndexedColumn
> create zone if not exists "AIMEM" engine aimem
> create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
> SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
> null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
> create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
> {noformat}
> The following error is seen in the log of the first node at this time:
>
> {noformat}
> 2024-03-28 02:42:38:675 +
> [WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
> index=1534, not found]]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
> at
> org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
> at
> org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
> at
> org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 2024-03-28 02:42:38:674 +
> [INFO][%DropColumnsTest_cluster_0%build-index-1][IndexBuildTask] Index build
> completed: [tableId=83, partitionId=0, indexId=85]
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-4][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-9][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-3][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-5][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-0][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> 2024-03-28 02:42:38:720 +
> [ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-1][NodeImpl] Node
> append [0, 0] failed,
> status=Status[EIO<1014>: Corrupted LogStorage].
> {noformat}
> On the second node:
> {noformat}
> 2024-03-28 02:42:49:143 +
> [ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
> Error processing the operation to delete the partition index
[jira] [Updated] (IGNITE-21860) DDL operations hang after creating an index
[
https://issues.apache.org/jira/browse/IGNITE-21860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-21860:
Description:
ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
h1. Setup:
* 2 server nodes
h1. Test:
A set of DDL operations which creates test tables with different field types,
creates an index over one or more fields and then drops the index. See the
attached [^drop_index_test_ddl.txt]
h1. Expected result:
The test passes
h1. Actual result:
The test hangs after executing the following set of operations:
{noformat}
drop table if exists dropIndexedColumn
create zone if not exists "AIMEM" engine aimem
create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
{noformat}
The following error is seen in the log of the first node at this time:
{noformat}
2024-03-28 02:42:38:675 +
[WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
FSMCaller already in error status, ignore new error
Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
index=1534, not found]]
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
at
org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
at
org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
at
org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
at
org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
at
org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
2024-03-28 02:42:38:674 +
[INFO][%DropColumnsTest_cluster_0%build-index-1][IndexBuildTask] Index build
completed: [tableId=83, partitionId=0, indexId=85]
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-4][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-9][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-3][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-5][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-0][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
2024-03-28 02:42:38:720 +
[ERROR][%DropColumnsTest_cluster_0%JRaft-Common-Executor-1][NodeImpl] Node
append [0, 0] failed,
status=Status[EIO<1014>: Corrupted LogStorage].
{noformat}
On the second node:
{noformat}
2024-03-28 02:42:49:143 +
[ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
Error processing the operation to delete the partition index building key:
[indexId=85, partitionId=11]
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
at
[jira] [Commented] (IGNITE-21860) DDL operations hang after creating an index
[
https://issues.apache.org/jira/browse/IGNITE-21860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831675#comment-17831675
]
Ivan Artiukhov commented on IGNITE-21860:
-
Attached the full logs from these two nodes.
> DDL operations hang after creating an index
> ---
>
> Key: IGNITE-21860
> URL: https://issues.apache.org/jira/browse/IGNITE-21860
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: drop_index_test_ddl.txt, node1.log, node2.log
>
>
> ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
> h1. Setup:
> * 2 server nodes
> h1. Test:
> A set of DDL operations which creates test tables with different field types,
> creates an index over one or more fields and then drops the index. See the
> attached [^drop_index_test_ddl.txt]
> h1. Expected result:
> The test passes
> h1. Actual result:
> The test hangs after executing the following set of operations:
>
> {noformat}
> drop table if exists dropIndexedColumn
> create zone if not exists "AIMEM" engine aimem
> create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
> SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
> null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
> create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
> {noformat}
> The following error is seen in the log of the first node at this time:
>
> {noformat}
> 2024-03-28 02:42:38:675 +
> [WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
> index=1534, not found]]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
> at
> org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
> at
> org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
> at
> org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> On the second node:
> {noformat}
> 2024-03-28 02:42:49:143 +
> [ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
> Error processing the operation to delete the partition index building key:
> [indexId=85, partitionId=11]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
[jira] [Created] (IGNITE-21860) DDL operations hang after creating an index
Ivan Artiukhov created IGNITE-21860:
---
Summary: DDL operations hang after creating an index
Key: IGNITE-21860
URL: https://issues.apache.org/jira/browse/IGNITE-21860
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Ivan Artiukhov
Attachments: drop_index_test_ddl.txt
ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
h1. Setup:
* 2 server nodes
h1. Test:
A set of DDL operations which creates test tables with different field types,
creates an index over one or more fields and then drops the index. See the
attached [^drop_index_test_ddl.txt]
h1. Expected result:
The test passes
h1. Actual result:
The test hangs after executing the following set of operations:
{noformat}
drop table if exists dropIndexedColumn
create zone if not exists "AIMEM" engine aimem
create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
{noformat}
The following error is seen in the log of the first node at this time:
{noformat}
2024-03-28 02:42:38:675 +
[WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
FSMCaller already in error status, ignore new error
Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
index=1534, not found]]
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
at
org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
at
org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
at
org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
at
org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
at
org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
On the second node:
{noformat}
2024-03-28 02:42:49:143 +
[ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
Error processing the operation to delete the partition index building key:
[indexId=85, partitionId=11]
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.util.concurrent.TimeoutException
... 8 more
{noformat}
After this there is no way to execute the following DDL (it hangs): {{drop
table if exists dropNoMoreIndexedColumn}}
h1. Notes:
* Reproduced only once and only with {{aimem}} storage engine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21860) DDL operations hang after creating an index
[
https://issues.apache.org/jira/browse/IGNITE-21860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-21860:
Attachment: node1.log
> DDL operations hang after creating an index
> ---
>
> Key: IGNITE-21860
> URL: https://issues.apache.org/jira/browse/IGNITE-21860
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: drop_index_test_ddl.txt, node1.log, node2.log
>
>
> ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
> h1. Setup:
> * 2 server nodes
> h1. Test:
> A set of DDL operations which creates test tables with different field types,
> creates an index over one or more fields and then drops the index. See the
> attached [^drop_index_test_ddl.txt]
> h1. Expected result:
> The test passes
> h1. Actual result:
> The test hangs after executing the following set of operations:
>
> {noformat}
> drop table if exists dropIndexedColumn
> create zone if not exists "AIMEM" engine aimem
> create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
> SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
> null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
> create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
> {noformat}
> The following error is seen in the log of the first node at this time:
>
> {noformat}
> 2024-03-28 02:42:38:675 +
> [WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
> index=1534, not found]]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
> at
> org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
> at
> org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
> at
> org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> On the second node:
> {noformat}
> 2024-03-28 02:42:49:143 +
> [ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
> Error processing the operation to delete the partition index building key:
> [indexId=85, partitionId=11]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by:
[jira] [Updated] (IGNITE-21860) DDL operations hang after creating an index
[
https://issues.apache.org/jira/browse/IGNITE-21860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-21860:
Attachment: node2.log
> DDL operations hang after creating an index
> ---
>
> Key: IGNITE-21860
> URL: https://issues.apache.org/jira/browse/IGNITE-21860
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: drop_index_test_ddl.txt, node1.log, node2.log
>
>
> ignite3, rev. ae643bd31f329ac2ce877cc51eaa2c6a1f1a8a21
> h1. Setup:
> * 2 server nodes
> h1. Test:
> A set of DDL operations which creates test tables with different field types,
> creates an index over one or more fields and then drops the index. See the
> attached [^drop_index_test_ddl.txt]
> h1. Expected result:
> The test passes
> h1. Actual result:
> The test hangs after executing the following set of operations:
>
> {noformat}
> drop table if exists dropIndexedColumn
> create zone if not exists "AIMEM" engine aimem
> create table dropIndexedColumn(k1 SMALLINT not null, v0 TINYINT not null, v1
> SMALLINT not null, v2 INTEGER not null, v3 BIGINT not null, v4 VARCHAR not
> null, v5 TIMESTAMP not null, primary key (k1)) with PRIMARY_ZONE='AIMEM'
> create index dropIndexedColumn_v1idx on dropIndexedColumn using TREE (v1)
> {noformat}
> The following error is seen in the log of the first node at this time:
>
> {noformat}
> 2024-03-28 02:42:38:675 +
> [WARNING][%DropColumnsTest_cluster_0%JRaft-Common-Executor-8][FSMCallerImpl]
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EIO<1014>: Corrupted entry at
> index=1534, not found]]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:595)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.getEntry(LogManagerImpl.java:798)
> at
> org.apache.ignite.raft.jraft.core.Replicator.prepareEntry(Replicator.java:820)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1645)
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
> at
> org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
> at
> org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1205)
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$notifyOnNewLog$9(LogManagerImpl.java:1159)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> On the second node:
> {noformat}
> 2024-03-28 02:42:49:143 +
> [ERROR][%DropColumnsTest_cluster_1%Raft-Group-Client-8][IndexAvailabilityController]
> Error processing the operation to delete the partition index building key:
> [indexId=85, partitionId=11]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:550)
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$44(RaftGroupServiceImpl.java:653)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by:
[jira] [Updated] (IGNITE-21722) Sql. NPE in correlated nested loop join
[
https://issues.apache.org/jira/browse/IGNITE-21722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21722:
--
Labels: calcite2-required ignite-3 (was: ignite-3)
> Sql. NPE in correlated nested loop join
> ---
>
> Key: IGNITE-21722
> URL: https://issues.apache.org/jira/browse/IGNITE-21722
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: calcite2-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See stack trace below:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.join(CorrelatedNestedLoopJoinNode.java:362)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.CorrelatedNestedLoopJoinNode.lambda$onRequest$1(CorrelatedNestedLoopJoinNode.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
> ... 4 more
> {code}
> To reproduce the issue, run TPC-H q21 with sf=0.1 on 3-node cluster
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21859) Causality token stays 0 for default zone
Ivan Zlenko created IGNITE-21859:
Summary: Causality token stays 0 for default zone
Key: IGNITE-21859
URL: https://issues.apache.org/jira/browse/IGNITE-21859
Project: Ignite
Issue Type: Task
Affects Versions: 3.0.0-beta1
Reporter: Ivan Zlenko
We have a problem where if no alter or other action was performed on default
zone causality token in CatalogZoneDescriptor will remain 0.
It will cause an error on any attempt of rebalacing any tables in that zone:
{code}
[2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
Failed to update stable keys for tables [[TESTTABLE]]
{code}
If we will add stacktrace to output we will get following:
{code}
[2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
CATCH,
java.lang.IllegalArgumentException: causalityToken must be greater then zero
[causalityToken=0"
at
org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
at
org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[?:?]
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
{code}
The workaround is creating a zone and specifying this zone to table.
Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21858) Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages
[
https://issues.apache.org/jira/browse/IGNITE-21858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21858:
-
Description:
In https://issues.apache.org/jira/browse/IGNITE-18991 we moved
stable/pending/planned keys handling to zone, and now they work with
{{ZonePartitionId}}, but all these changes lead to changes in PlacementDriver
api changes, because the accepted {{ReplicationGroupId}} which is
{{TablePartitionId}}.
We need to change all places where {{PlacementDriver}} API is used and where
{{TablePartitionId}} is passed
was:In https://issues.apache.org/jira/browse/IGNITE-18991 we moved
stable/pending/planned keys handling to zone, and now they work with
{{ZonePartitionId}}, but all these changes lead to changes in PlacementDriver
api changes, because the accepted {{ReplicationGroupId}} which is
> Move from TablePartitionId to ZonePartitionId for all PlacementDriver API
> usages
>
>
> Key: IGNITE-21858
> URL: https://issues.apache.org/jira/browse/IGNITE-21858
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-18991 we moved
> stable/pending/planned keys handling to zone, and now they work with
> {{ZonePartitionId}}, but all these changes lead to changes in PlacementDriver
> api changes, because the accepted {{ReplicationGroupId}} which is
> {{TablePartitionId}}.
> We need to change all places where {{PlacementDriver}} API is used and where
> {{TablePartitionId}} is passed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21858) Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages
[
https://issues.apache.org/jira/browse/IGNITE-21858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21858:
-
Description: In https://issues.apache.org/jira/browse/IGNITE-18991 we moved
stable/pending/planned keys handling to zone, and now they work with
{{ZonePartitionId}}, but all these changes lead to changes in PlacementDriver
api changes, because the accepted {{ReplicationGroupId}} which is (was: In
https://issues.apache.org/jira/browse/IGNITE-18991 we moved
stable/pending/planned keys handling to zone, and now they work with )
> Move from TablePartitionId to ZonePartitionId for all PlacementDriver API
> usages
>
>
> Key: IGNITE-21858
> URL: https://issues.apache.org/jira/browse/IGNITE-21858
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> In https://issues.apache.org/jira/browse/IGNITE-18991 we moved
> stable/pending/planned keys handling to zone, and now they work with
> {{ZonePartitionId}}, but all these changes lead to changes in PlacementDriver
> api changes, because the accepted {{ReplicationGroupId}} which is
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21858) Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages
[ https://issues.apache.org/jira/browse/IGNITE-21858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21858: - Description: In https://issues.apache.org/jira/browse/IGNITE-18991 we moved stable/pending/planned keys handling to zone, and now they work with > Move from TablePartitionId to ZonePartitionId for all PlacementDriver API > usages > > > Key: IGNITE-21858 > URL: https://issues.apache.org/jira/browse/IGNITE-21858 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-18991 we moved > stable/pending/planned keys handling to zone, and now they work with -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21858) Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages
Mirza Aliev created IGNITE-21858: Summary: Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages Key: IGNITE-21858 URL: https://issues.apache.org/jira/browse/IGNITE-21858 Project: Ignite Issue Type: Improvement Reporter: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21858) Move from TablePartitionId to ZonePartitionId for all PlacementDriver API usages
[ https://issues.apache.org/jira/browse/IGNITE-21858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-21858: Assignee: Mirza Aliev > Move from TablePartitionId to ZonePartitionId for all PlacementDriver API > usages > > > Key: IGNITE-21858 > URL: https://issues.apache.org/jira/browse/IGNITE-21858 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21857) Improvements. Update AsmMarshallerGenerator to generate unmarshalKeyOnly method to support arbitrary key column order.
Maksim Zhuravkov created IGNITE-21857: - Summary: Improvements. Update AsmMarshallerGenerator to generate unmarshalKeyOnly method to support arbitrary key column order. Key: IGNITE-21857 URL: https://issues.apache.org/jira/browse/IGNITE-21857 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov AsmMarshaller should define unmarshalKeyOnly method to be used a replacement for reflection based marshaller. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21857) Improvements. Update AsmMarshallerGenerator to generate unmarshalKeyOnly method to support arbitrary key column order.
[ https://issues.apache.org/jira/browse/IGNITE-21857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21857: -- Labels: ignite-3 (was: ) > Improvements. Update AsmMarshallerGenerator to generate unmarshalKeyOnly > method to support arbitrary key column order. > - > > Key: IGNITE-21857 > URL: https://issues.apache.org/jira/browse/IGNITE-21857 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > AsmMarshaller should define unmarshalKeyOnly method to be used a replacement > for reflection based marshaller. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21777) 'Failed to get the primary replica' or 'Replication is timed out' or hangs with 'aimem' storage engine
[
https://issues.apache.org/jira/browse/IGNITE-21777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov resolved IGNITE-21777.
Resolution: Cannot Reproduce
> 'Failed to get the primary replica' or 'Replication is timed out' or hangs
> with 'aimem' storage engine
> --
>
> Key: IGNITE-21777
> URL: https://issues.apache.org/jira/browse/IGNITE-21777
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta2
> Environment: Cluster of 2 nodes.
> Storage engine - aimem.
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> # Create a cluster with 2 nodes.
> # Connect via JDBC.
> # Repeat the following SQL statements in a loop (for example, 100 times):
> ** {{drop table if exists tags}}
> ** {{create zone if not exists "AIMEM" engine aimem}}
> ** {{create table tags(tagId integer not null, tag varchar(100) not null,
> primary key (tagId)) with PRIMARY_ZONE='AIMEM'}}
> ** {{insert into tags(tagId, tag) values (1,'unit'), (2,'integration'),
> (3,'smoke'), (4,'sanity'), (5,'regression')}}
> *Expected result:*
> No errors or hangs happen.
> *Actual result:*
> Hangs on {{Create table}} or {{Insert into}} statement.
> _*OR*_
> Get the error {{Replication is timed out}}
> {code:java}
> Replication is timed out [replicaGrpId=34_part_16]
> java.sql.SQLException: Replication is timed out [replicaGrpId=34_part_16]
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:181)
> at
> org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeUpdateQuery(JdbcSteps.java:116)
> at
> org.gridgain.ai3tests.tests.UpdateTests.wannaCatchTheBug(UpdateTests.java:95)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834) {code}
> _*OR*_
> Get the error {{Failed to get the primary replica}}
> {code:java}
> java.sql.SQLException: Failed to get the primary replica
> [tablePartitionId=18_part_1]
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:181)
> at
> org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeUpdateQuery(JdbcSteps.java:116)
> at
> org.gridgain.ai3tests.tests.UpdateTests.createAndFillTables(UpdateTests.java:247)
> at io.qameta.allure.Allure.lambda$step$0(Allure.java:113)
> at io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at io.qameta.allure.Allure.step(Allure.java:181)
> at io.qameta.allure.Allure.step(Allure.java:125)
> at io.qameta.allure.Allure.step(Allure.java:112)
> at
> org.gridgain.ai3tests.tests.UpdateTests.updateTableWithConditionThatHasLinkedInnerSubQueries(UpdateTests.java:147)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21856) Unable to insert values with exponent values >=39 for FLOAT and REAL
[
https://issues.apache.org/jira/browse/IGNITE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anatoli Karman updated IGNITE-21856:
Component/s: sql
> Unable to insert values with exponent values >=39 for FLOAT and REAL
>
>
> Key: IGNITE-21856
> URL: https://issues.apache.org/jira/browse/IGNITE-21856
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Anatoli Karman
>Priority: Major
> Labels: ignite-3
>
> Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*})
> for FLOAT and REAL data type columns results in an error.
> *Please note that this issue is present only for IG3.*
>
> {*}Steps to reproduce{*}:
> - send an insert query where a value for REAL or FLOAT column is
> *{{3.4028235E39}}*
> {code:java}
> insert into test_e011_REAL (key_field, field1_REAL) values (3,
> 3.4028235E39);{code}
>
> *Expected result:*
> Data has been successfully inserted in the table.
> The data returned upon respective select query:
> {code:java}
> '3','Infinity'{code}
>
> *Actual result:*
> Data has not been inserted.
> The following error is present:
> {code:java}
> Character I is neither a decimal digit number, decimal point, nor "e"
> notation exponential mark.{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21856) Unable to insert values with exponent values >=39 for FLOAT and REAL
[
https://issues.apache.org/jira/browse/IGNITE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anatoli Karman updated IGNITE-21856:
Description:
Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*}) for
FLOAT and REAL data type columns results in an error.
*Please note that this issue is present only for IG3.*
{*}Steps to reproduce{*}:
- send an insert query where a value for REAL or FLOAT column is
*{{3.4028235E39}}*
{code:java}
insert into test_e011_REAL (key_field, field1_REAL) values (3,
3.4028235E39);{code}
*Expected result:*
Data has been successfully inserted in the table.
The data returned upon respective select query:
{code:java}
'3','Infinity'{code}
*Actual result:*
Data has not been inserted.
The following error is present:
{code:java}
Character I is neither a decimal digit number, decimal point, nor "e" notation
exponential mark.{code}
was:
Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*}) for
FLOAT and REAL data type columns results in an error.
{*}Steps to reproduce{*}:
- send an insert query where a value for REAL or FLOAT column is
*{{3.4028235E39}}*
{code:java}
insert into test_e011_REAL (key_field, field1_REAL) values (3,
3.4028235E39);{code}
*Expected result:*
Data has been successfully inserted in the table.
The data returned upon respective select query:
{code:java}
'3','Infinity'{code}
*Actual result:*
Data has not been inserted.
The following error is present:
{code:java}
Character I is neither a decimal digit number, decimal point, nor "e" notation
exponential mark.{code}
*Please note that this issue is present only for IG3.*
> Unable to insert values with exponent values >=39 for FLOAT and REAL
>
>
> Key: IGNITE-21856
> URL: https://issues.apache.org/jira/browse/IGNITE-21856
> Project: Ignite
> Issue Type: Bug
>Reporter: Anatoli Karman
>Priority: Major
> Labels: ignite-3
>
> Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*})
> for FLOAT and REAL data type columns results in an error.
> *Please note that this issue is present only for IG3.*
>
> {*}Steps to reproduce{*}:
> - send an insert query where a value for REAL or FLOAT column is
> *{{3.4028235E39}}*
> {code:java}
> insert into test_e011_REAL (key_field, field1_REAL) values (3,
> 3.4028235E39);{code}
>
> *Expected result:*
> Data has been successfully inserted in the table.
> The data returned upon respective select query:
> {code:java}
> '3','Infinity'{code}
>
> *Actual result:*
> Data has not been inserted.
> The following error is present:
> {code:java}
> Character I is neither a decimal digit number, decimal point, nor "e"
> notation exponential mark.{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21856) Unable to insert values with exponent values >=39 for FLOAT and REAL
[
https://issues.apache.org/jira/browse/IGNITE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anatoli Karman updated IGNITE-21856:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Unable to insert values with exponent values >=39 for FLOAT and REAL
>
>
> Key: IGNITE-21856
> URL: https://issues.apache.org/jira/browse/IGNITE-21856
> Project: Ignite
> Issue Type: Bug
>Reporter: Anatoli Karman
>Priority: Major
> Labels: ignite-3
>
> Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*})
> for FLOAT and REAL data type columns results in an error.
>
> {*}Steps to reproduce{*}:
> - send an insert query where a value for REAL or FLOAT column is
> *{{3.4028235E39}}*
>
> {code:java}
> insert into test_e011_REAL (key_field, field1_REAL) values (3,
> 3.4028235E39);{code}
>
> *Expected result:*
> Data has been successfully inserted in the table.
> The data returned upon respective select query:
> {code:java}
> '3','Infinity'{code}
>
> *Actual result:*
> Data has not been inserted.
> The following error is present:
> {code:java}
> Character I is neither a decimal digit number, decimal point, nor "e"
> notation exponential mark.{code}
>
> *Please note that this issue is present only for IG3.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21856) Unable to insert values with exponent values >=39 for FLOAT and REAL
[
https://issues.apache.org/jira/browse/IGNITE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anatoli Karman updated IGNITE-21856:
Description:
Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*}) for
FLOAT and REAL data type columns results in an error.
{*}Steps to reproduce{*}:
- send an insert query where a value for REAL or FLOAT column is
*{{3.4028235E39}}*
{code:java}
insert into test_e011_REAL (key_field, field1_REAL) values (3,
3.4028235E39);{code}
*Expected result:*
Data has been successfully inserted in the table.
The data returned upon respective select query:
{code:java}
'3','Infinity'{code}
*Actual result:*
Data has not been inserted.
The following error is present:
{code:java}
Character I is neither a decimal digit number, decimal point, nor "e" notation
exponential mark.{code}
*Please note that this issue is present only for IG3.*
was:
Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*}) for
FLOAT and REAL data type columns results in an error.
{*}Steps to reproduce{*}:
- send an insert query where a value for REAL or FLOAT column is
*{{3.4028235E39}}*
{code:java}
insert into test_e011_REAL (key_field, field1_REAL) values (3,
3.4028235E39);{code}
*Expected result:*
Data has been successfully inserted in the table.
The data returned upon respective select query:
{code:java}
'3','Infinity'{code}
*Actual result:*
Data has not been inserted.
The following error is present:
{code:java}
Character I is neither a decimal digit number, decimal point, nor "e" notation
exponential mark.{code}
*Please note that this issue is present only for IG3.*
> Unable to insert values with exponent values >=39 for FLOAT and REAL
>
>
> Key: IGNITE-21856
> URL: https://issues.apache.org/jira/browse/IGNITE-21856
> Project: Ignite
> Issue Type: Bug
>Reporter: Anatoli Karman
>Priority: Major
> Labels: ignite-3
>
> Insert queries for values with exponent >=39 (e.g. {*}{{3.4028235E39}}{*})
> for FLOAT and REAL data type columns results in an error.
>
> {*}Steps to reproduce{*}:
> - send an insert query where a value for REAL or FLOAT column is
> *{{3.4028235E39}}*
> {code:java}
> insert into test_e011_REAL (key_field, field1_REAL) values (3,
> 3.4028235E39);{code}
>
> *Expected result:*
> Data has been successfully inserted in the table.
> The data returned upon respective select query:
> {code:java}
> '3','Infinity'{code}
>
> *Actual result:*
> Data has not been inserted.
> The following error is present:
> {code:java}
> Character I is neither a decimal digit number, decimal point, nor "e"
> notation exponential mark.{code}
>
> *Please note that this issue is present only for IG3.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
