[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21391:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
ItNodeTest.java:2568 is
{code:java}
assertTrue(cluster.start(findById(peers, oldLeaderAddr)));{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> ItNodeTest.java:2568 is
> {code:java}
> assertTrue(cluster.start(findById(peers, oldLeaderAddr)));{code}
> Didn't manage to reproduce the issue locally, however there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21391: - Epic Link: IGNITE-21389 > ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky > --- > > Key: IGNITE-21391 > URL: https://issues.apache.org/jira/browse/IGNITE-21391 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21391: - Labels: ignite-3 (was: ) > ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky > --- > > Key: IGNITE-21391 > URL: https://issues.apache.org/jira/browse/IGNITE-21391 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21391: - Ignite Flags: (was: Docs Required,Release Notes Required) > ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky > --- > > Key: IGNITE-21391 > URL: https://issues.apache.org/jira/browse/IGNITE-21391 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
Alexander Lapin created IGNITE-21391: Summary: ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky Key: IGNITE-21391 URL: https://issues.apache.org/jira/browse/IGNITE-21391 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15889) Add 'contains' method to Record API
[
https://issues.apache.org/jira/browse/IGNITE-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812174#comment-17812174
]
Mikhail Efremov commented on IGNITE-15889:
--
[~amashenkov] Hi, I did the pull request, but have several questions:
# I have registered in TC, but have no access to the project and can't view
check logs without help. Can you grant me kind of viewer access in TC? The
username is the same as in JIRA.
# I launched gradle test task, It failed, but the failed test relates to
logging module {{{}ClientLoggingTest::testBasicLogging{}}}, I'm not sure should
I to fix it or not?
Thank you~
> Add 'contains' method to Record API
> ---
>
> Key: IGNITE-15889
> URL: https://issues.apache.org/jira/browse/IGNITE-15889
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3, newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There is no method in Record API with the same semantic as the 'contains'
> method in KV views.
> Add *RecordView.contains* similar to *KeyValueView.contains*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21390) Inconsistent behavior of Compute APIs when target node does not exist
[
https://issues.apache.org/jira/browse/IGNITE-21390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21390:
Description:
*IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
that does not exist in the cluster, the API behavior is confusing and
inconsistent across embedded and thin client modes:
{code:java}
var fakeNode = new ClusterNodeImpl("fakeId", "fakeName", new
NetworkAddress("localhost", 12345));
JobExecution execution =
ignite.compute().executeAsync(Set.of(fakeNode), units(), "job", null);
execution.resultAsync().join();
{code}
was:*IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single
node that does not exist in the cluster (e.g. {{new ClusterNodeImpl("fakeId",
"fakeName", new NetworkAddress("localhost", 12345))}}):
> Inconsistent behavior of Compute APIs when target node does not exist
> -
>
> Key: IGNITE-21390
> URL: https://issues.apache.org/jira/browse/IGNITE-21390
> Project: Ignite
> Issue Type: Bug
> Components: compute, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
> that does not exist in the cluster, the API behavior is confusing and
> inconsistent across embedded and thin client modes:
> {code:java}
> var fakeNode = new ClusterNodeImpl("fakeId", "fakeName", new
> NetworkAddress("localhost", 12345));
> JobExecution execution =
> ignite.compute().executeAsync(Set.of(fakeNode), units(), "job", null);
> execution.resultAsync().join();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21390) Inconsistent behavior of Compute APIs when target node does not exist
[
https://issues.apache.org/jira/browse/IGNITE-21390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21390:
Description:
*IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
that does not exist in the cluster, the API behavior is confusing and
inconsistent across embedded and thin client modes:
{code:java}
var fakeNode = new ClusterNodeImpl("fakeId", "fakeName", new
NetworkAddress("localhost", 12345));
JobExecution execution =
ignite.compute().executeAsync(Set.of(fakeNode), units(), "job", null);
execution.resultAsync().join();
{code}
* Client: throws "Specified node is not present in the cluster" exception with
a generic error code (uses deprecated constructor)
* Embedded: actually tries to connect to the specified address and throws
"io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
refused: localhost/127.0.0.1:12345"
Ensure consistent behavior; probably add a dedicated error code.
was:
*IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
that does not exist in the cluster, the API behavior is confusing and
inconsistent across embedded and thin client modes:
{code:java}
var fakeNode = new ClusterNodeImpl("fakeId", "fakeName", new
NetworkAddress("localhost", 12345));
JobExecution execution =
ignite.compute().executeAsync(Set.of(fakeNode), units(), "job", null);
execution.resultAsync().join();
{code}
> Inconsistent behavior of Compute APIs when target node does not exist
> -
>
> Key: IGNITE-21390
> URL: https://issues.apache.org/jira/browse/IGNITE-21390
> Project: Ignite
> Issue Type: Bug
> Components: compute, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
> that does not exist in the cluster, the API behavior is confusing and
> inconsistent across embedded and thin client modes:
> {code:java}
> var fakeNode = new ClusterNodeImpl("fakeId", "fakeName", new
> NetworkAddress("localhost", 12345));
> JobExecution execution =
> ignite.compute().executeAsync(Set.of(fakeNode), units(), "job", null);
> execution.resultAsync().join();
> {code}
> * Client: throws "Specified node is not present in the cluster" exception
> with a generic error code (uses deprecated constructor)
> * Embedded: actually tries to connect to the specified address and throws
> "io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: localhost/127.0.0.1:12345"
> Ensure consistent behavior; probably add a dedicated error code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21390) Inconsistent behavior of Compute APIs when target node does not exist
[
https://issues.apache.org/jira/browse/IGNITE-21390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21390:
Description: *IgniteCompute.executeAsync* accepts a set of nodes. If we
pass a single node that does not exist in the cluster (e.g. {{new
ClusterNodeImpl("fakeId", "fakeName", new NetworkAddress("localhost",
12345))}}):
> Inconsistent behavior of Compute APIs when target node does not exist
> -
>
> Key: IGNITE-21390
> URL: https://issues.apache.org/jira/browse/IGNITE-21390
> Project: Ignite
> Issue Type: Bug
> Components: compute, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *IgniteCompute.executeAsync* accepts a set of nodes. If we pass a single node
> that does not exist in the cluster (e.g. {{new ClusterNodeImpl("fakeId",
> "fakeName", new NetworkAddress("localhost", 12345))}}):
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21390) Inconsistent behavior of Compute APIs when target node does not exist
Pavel Tupitsyn created IGNITE-21390: --- Summary: Inconsistent behavior of Compute APIs when target node does not exist Key: IGNITE-21390 URL: https://issues.apache.org/jira/browse/IGNITE-21390 Project: Ignite Issue Type: Bug Components: compute, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21389) TX&PME TC Green Again Backlog
Alexander Lapin created IGNITE-21389: Summary: TX&PME TC Green Again Backlog Key: IGNITE-21389 URL: https://issues.apache.org/jira/browse/IGNITE-21389 Project: Ignite Issue Type: Epic Reporter: Alexander Lapin Epic to aggregate bugs created from within daily TC analysis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21389) TX&PME TC Green Again Backlog
[ https://issues.apache.org/jira/browse/IGNITE-21389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21389: - Ignite Flags: (was: Docs Required,Release Notes Required) > TX&PME TC Green Again Backlog > - > > Key: IGNITE-21389 > URL: https://issues.apache.org/jira/browse/IGNITE-21389 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > > Epic to aggregate bugs created from within daily TC analysis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20119) Switch index to STOPPING state as a reaction to DROP INDEX
[ https://issues.apache.org/jira/browse/IGNITE-20119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-20119: -- Assignee: Roman Puchkovskiy > Switch index to STOPPING state as a reaction to DROP INDEX > -- > > Key: IGNITE-20119 > URL: https://issues.apache.org/jira/browse/IGNITE-20119 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20894: - Fix Version/s: 3.0.0-beta2 (was: 3.0) > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20894: - Ignite Flags: (was: Docs Required,Release Notes Required) > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20894: - Fix Version/s: 3.0 (was: 3.0.0-beta2) > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20894: - Fix Version/s: 3.0.0-beta2 (was: 3.0) > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20858) Compute error handling
[ https://issues.apache.org/jira/browse/IGNITE-20858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20858: -- Assignee: Ivan Gagarkin > Compute error handling > -- > > Key: IGNITE-20858 > URL: https://issues.apache.org/jira/browse/IGNITE-20858 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Igor Sapego >Assignee: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > Make sure that compute follows AI3 Error Handling rules, defined in > IGNITE-14611. More specifically: > - We should never throw to user anything that is not IgniteException, > IgniteCheckedException or a public class derived from one of them; > - Make sure exceptions thrown by a user code are wrapped by IgniteException > and have a meaningful message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21388) Remove default storage profile for LogicalNode
Kirill Gusakov created IGNITE-21388: --- Summary: Remove default storage profile for LogicalNode Key: IGNITE-21388 URL: https://issues.apache.org/jira/browse/IGNITE-21388 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21387) Recovery is not possible, if node have no needed storage profile
Kirill Gusakov created IGNITE-21387: --- Summary: Recovery is not possible, if node have no needed storage profile Key: IGNITE-21387 URL: https://issues.apache.org/jira/browse/IGNITE-21387 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov Looks like any table try to create storages on the recovery node, even if is shouldn't be here, because of zone storage profile filter -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21386) Fix hot loading for storage profiles if needed
Kirill Gusakov created IGNITE-21386: --- Summary: Fix hot loading for storage profiles if needed Key: IGNITE-21386 URL: https://issues.apache.org/jira/browse/IGNITE-21386 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21385) Remove dataStorage
[ https://issues.apache.org/jira/browse/IGNITE-21385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21385: Ignite Flags: (was: Docs Required,Release Notes Required) > Remove dataStorage > --- > > Key: IGNITE-21385 > URL: https://issues.apache.org/jira/browse/IGNITE-21385 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21385) Remove dataStorage
Kirill Gusakov created IGNITE-21385: --- Summary: Remove dataStorage Key: IGNITE-21385 URL: https://issues.apache.org/jira/browse/IGNITE-21385 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21384) Initialize all rows with new column's default value
Maksim Myskov created IGNITE-21384:
--
Summary: Initialize all rows with new column's default value
Key: IGNITE-21384
URL: https://issues.apache.org/jira/browse/IGNITE-21384
Project: Ignite
Issue Type: New Feature
Reporter: Maksim Myskov
In case of adding a new column with a default value specified (for example:
ALTER TABLE ADD COLUMN col INT DEFAULT 10), all existing rows (that were added
before "alter table") must be initialized with a new value.
h3. Current behaviour
The default value of a column is evaluated on read.
h3. Motivation
This is a pre-requisite for adding arbitrary expressions as default values.
Let's imagine a simple case:
{code:sql}
ALTER TABLE ADD COLUMN modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP
{code}
With the current behavior for all existing rows the value of "modified" column
will be evaluated on every read.
Many DBs use the proposed behavior:
* PostgreSQL
* CockroachDB
* Yugabyte
For example, from PostgreSQL
[docs|https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-NOTES]:
{noformat}
Adding a column with a volatile DEFAULT or changing the type of an existing
column will require the entire table and its indexes to be rewritten.
{noformat}
h3. Downsides
Adding a new column with a default value will be a much more expensive
operation and can take a significant time on large tables
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21383) Optimize binary tuple creation
[
https://issues.apache.org/jira/browse/IGNITE-21383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21383:
---
Labels: ignite-3 performance (was: ignite-3)
> Optimize binary tuple creation
> --
>
> Key: IGNITE-21383
> URL: https://issues.apache.org/jira/browse/IGNITE-21383
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: TupleBuildGraph.png
>
>
> h3. Motivation
> Currently, the KV API requires a key tuple to get or put a value. There is a
> typical pattern:
> {code}
> kvView.put(null, Tuple.create().set("key", i), Tuple.create().set("valInt",
> i));
> kvView.get(null, Tuple.create().set("key", i));
> {code}
> Beside that, we spend more time validating field name limitations.
> !TupleBuildGraph.png!
> h3. Definition of done
> We do not parse field names to put or get values from KV views.
> Probably we will be able to make a tuple template for the known table schema
> and provide access to it through an API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21383) Optimize binary tuple creation
[
https://issues.apache.org/jira/browse/IGNITE-21383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21383:
---
Description:
h3. Motivation
Currently, the KV API requires a key tuple to get or put a value. There is a
typical pattern:
{code}
kvView.put(null, Tuple.create().set("key", i), Tuple.create().set("valInt", i));
kvView.get(null, Tuple.create().set("key", i));
{code}
Beside that, we spend more time validating field name limitations.
!TupleBuildGraph.png!
h3. Definition of done
We do not parse field names to put or get values from KV views.
Probably we will be able to make a tuple template for the known table schema
and provide access to it through an API.
was:
h3. Motivation
Currently, the KV API requires a key tuple to get or put a value. There is a
typical pattern:
{code}
kvView.put(null, Tuple.create().set("key", i), Tuple.create().set("valInt", i));
kvView.get(null, Tuple.create().set("key", i));
{code}
Beside that, we spend more time validating field name limitations.
h3. Definition of done
We do not parse field names to put or get values from KV views.
Probably we will be able to make a tuple template for the known table schema
and provide access to it through an API.
> Optimize binary tuple creation
> --
>
> Key: IGNITE-21383
> URL: https://issues.apache.org/jira/browse/IGNITE-21383
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: TupleBuildGraph.png
>
>
> h3. Motivation
> Currently, the KV API requires a key tuple to get or put a value. There is a
> typical pattern:
> {code}
> kvView.put(null, Tuple.create().set("key", i), Tuple.create().set("valInt",
> i));
> kvView.get(null, Tuple.create().set("key", i));
> {code}
> Beside that, we spend more time validating field name limitations.
> !TupleBuildGraph.png!
> h3. Definition of done
> We do not parse field names to put or get values from KV views.
> Probably we will be able to make a tuple template for the known table schema
> and provide access to it through an API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21383) Optimize binary tuple creation
Vladislav Pyatkov created IGNITE-21383:
--
Summary: Optimize binary tuple creation
Key: IGNITE-21383
URL: https://issues.apache.org/jira/browse/IGNITE-21383
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
Attachments: TupleBuildGraph.png
h3. Motivation
Currently, the KV API requires a key tuple to get or put a value. There is a
typical pattern:
{code}
kvView.put(null, Tuple.create().set("key", i), Tuple.create().set("valInt", i));
kvView.get(null, Tuple.create().set("key", i));
{code}
Beside that, we spend more time validating field name limitations.
h3. Definition of done
We do not parse field names to put or get values from KV views.
Probably we will be able to make a tuple template for the known table schema
and provide access to it through an API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-21381:
-
Description:
{{TopologyAwareRaftGroupServiceTest#testChangeLeaderForce}}
{{ActiveActorTest#testChangeLeaderForce}}
TBD
was:
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceTest#testChangeLeaderForce
org.apache.ignite.internal.placementdriver.ActiveActorTest#testChangeLeaderForce
TBD
> ActiveActorTest#testChangeLeaderForce is flaky
> ---
>
> Key: IGNITE-21381
> URL: https://issues.apache.org/jira/browse/IGNITE-21381
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{TopologyAwareRaftGroupServiceTest#testChangeLeaderForce}}
> {{ActiveActorTest#testChangeLeaderForce}}
> TBD
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21381: - Description: org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceTest#testChangeLeaderForce org.apache.ignite.internal.placementdriver.ActiveActorTest#testChangeLeaderForce TBD was:TBD > ActiveActorTest#testChangeLeaderForce is flaky > --- > > Key: IGNITE-21381 > URL: https://issues.apache.org/jira/browse/IGNITE-21381 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceTest#testChangeLeaderForce > org.apache.ignite.internal.placementdriver.ActiveActorTest#testChangeLeaderForce > TBD -- 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
]
Vladislav Pyatkov updated IGNITE-21382:
---
Description:
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.
was:
The test falls while waiting for the primary replica change. This issue si also
reproduced locally at lest one per 5 passes.
{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.
> 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
>Priority: Major
> Labels: ignite-3
>
> 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] [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
]
Vladislav Pyatkov updated IGNITE-21382:
---
Labels: ignite-3 (was: )
> 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
>Priority: Major
> Labels: ignite-3
>
> The test falls while waiting for the primary replica change. This issue si
> also reproduced locally at lest one per 5 passes.
> {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] [Created] (IGNITE-21382) Test ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling is flaky
Vladislav Pyatkov created IGNITE-21382:
--
Summary: 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
The test falls while waiting for the primary replica change. This issue si also
reproduced locally at lest one per 5 passes.
{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] [Created] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce is flaky
Mirza Aliev created IGNITE-21381: Summary: ActiveActorTest#testChangeLeaderForce is flaky Key: IGNITE-21381 URL: https://issues.apache.org/jira/browse/IGNITE-21381 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21380) Optimize lowWatermark update engine
[ https://issues.apache.org/jira/browse/IGNITE-21380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21380: - Description: The initial analysis showed that we have performance inefficiencies in lowWatermark engine, e.g. in readOnlyTxFutureById map. Let's prove that the proposed implementation is effective enough, or improve it if it's not. > Optimize lowWatermark update engine > --- > > Key: IGNITE-21380 > URL: https://issues.apache.org/jira/browse/IGNITE-21380 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > The initial analysis showed that we have performance inefficiencies in > lowWatermark engine, e.g. in readOnlyTxFutureById map. Let's prove that the > proposed implementation is effective enough, or improve it if it's not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20491) .NET: Thin 3.0: Introduce configurable operation timeout
[ https://issues.apache.org/jira/browse/IGNITE-20491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811934#comment-17811934 ] Pavel Tupitsyn commented on IGNITE-20491: - Merged to main: bdcc62f9c5c7ecbe0f8ce48092db6ce9a71d8cab > .NET: Thin 3.0: Introduce configurable operation timeout > > > Key: IGNITE-20491 > URL: https://issues.apache.org/jira/browse/IGNITE-20491 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we have `SocketTimeout` which is only used for handshake and > heartbeats, which means we use it to check if the server and network are > responsive. > However, other operations (put, get, compute, etc) can take any amount of > time. > Investigate if a general operation timeout can be useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21380) Optimize lowWatermark update engine
[ https://issues.apache.org/jira/browse/IGNITE-21380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21380: - Labels: ignite-3 performance (was: ) > Optimize lowWatermark update engine > --- > > Key: IGNITE-21380 > URL: https://issues.apache.org/jira/browse/IGNITE-21380 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21380) Optimize lowWatermark update engine
[ https://issues.apache.org/jira/browse/IGNITE-21380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21380: - Ignite Flags: (was: Docs Required,Release Notes Required) > Optimize lowWatermark update engine > --- > > Key: IGNITE-21380 > URL: https://issues.apache.org/jira/browse/IGNITE-21380 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21380) Optimize lowWatermark update engine
Alexander Lapin created IGNITE-21380: Summary: Optimize lowWatermark update engine Key: IGNITE-21380 URL: https://issues.apache.org/jira/browse/IGNITE-21380 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough
[ https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21379: - Description: h3. Motivation Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the performance perspective. Let's compare current implementation with common RW locks, CheckpointReadWriteLock, etc. Depending on the results it'll be required either to use faster implementation or re-consider busyLock idea itself because currently it brings significant performance drop. Given ticket is only about initial step - busyLock performance investigation. h3. Definition of Done * Prepare JMH benchmarks for busyLocks performance investigation. * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc in order to understand whether IgniteSpinBusyLock is fast enough. was: h3. Motivation Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the performance perspective. Let's compare current implementation with common RW locks, CheckpointReadWriteLock, etc. Depending on the results it'll be required either to use faster implementation or re-consider busyLock idea itself because currently it brings significant performance drop. Given ticket is only about initial step - busyLock performance investigation. > Investigate whether currently used busyLocks implementation is fast enough > -- > > Key: IGNITE-21379 > URL: https://issues.apache.org/jira/browse/IGNITE-21379 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > h3. Motivation > Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the > performance perspective. Let's compare current implementation with common RW > locks, CheckpointReadWriteLock, etc. Depending on the results it'll be > required either to use faster implementation or re-consider busyLock idea > itself because currently it brings significant performance drop. Given ticket > is only about initial step - busyLock performance investigation. > h3. Definition of Done > * Prepare JMH benchmarks for busyLocks performance investigation. > * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc > in order to understand whether IgniteSpinBusyLock is fast enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough.
[ https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21379: - Description: h3. Motivation Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the performance perspective. Let's compare current implementation with common RW locks, CheckpointReadWriteLock, etc. Depending on the results it'll be required either to use faster implementation or re-consider busyLock idea itself because currently it brings significant performance drop. Given ticket is only about initial step - busyLock performance investigation. > Investigate whether currently used busyLocks implementation is fast enough. > --- > > Key: IGNITE-21379 > URL: https://issues.apache.org/jira/browse/IGNITE-21379 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > h3. Motivation > Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the > performance perspective. Let's compare current implementation with common RW > locks, CheckpointReadWriteLock, etc. Depending on the results it'll be > required either to use faster implementation or re-consider busyLock idea > itself because currently it brings significant performance drop. Given ticket > is only about initial step - busyLock performance investigation. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough
[ https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21379: - Summary: Investigate whether currently used busyLocks implementation is fast enough (was: Investigate whether currently used busyLocks implementation is fast enough.) > Investigate whether currently used busyLocks implementation is fast enough > -- > > Key: IGNITE-21379 > URL: https://issues.apache.org/jira/browse/IGNITE-21379 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > h3. Motivation > Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the > performance perspective. Let's compare current implementation with common RW > locks, CheckpointReadWriteLock, etc. Depending on the results it'll be > required either to use faster implementation or re-consider busyLock idea > itself because currently it brings significant performance drop. Given ticket > is only about initial step - busyLock performance investigation. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough.
[ https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21379: - Labels: ignite-3 performance (was: ) > Investigate whether currently used busyLocks implementation is fast enough. > --- > > Key: IGNITE-21379 > URL: https://issues.apache.org/jira/browse/IGNITE-21379 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough.
[ https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21379: - Ignite Flags: (was: Docs Required,Release Notes Required) > Investigate whether currently used busyLocks implementation is fast enough. > --- > > Key: IGNITE-21379 > URL: https://issues.apache.org/jira/browse/IGNITE-21379 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Investigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Summary: Investigate whether it's possible to make txnState local map updates faster (was: Ivestigate whether it's possible to make txnState local map updates faster) > Investigate whether it's possible to make txnState local map updates faster > --- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > > h3. Motivation > IGNITE-21375 is about removing txnState local map updates within RO txn flow > because it brings us 20% performance drop. For RW transactions, it's however > not possible, because such updates are required by the RW protocol. Thus, it > seems reasonable to verify whether proposed VolatileTxStateMetaStorage is > itself fast enough. > h3. Definition of Done > * Increase VolatileTxStateMetaStorag performance if it's possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough.
Alexander Lapin created IGNITE-21379: Summary: Investigate whether currently used busyLocks implementation is fast enough. Key: IGNITE-21379 URL: https://issues.apache.org/jira/browse/IGNITE-21379 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21375) RO transactions should not update txnState local map
[ https://issues.apache.org/jira/browse/IGNITE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21375: - Summary: RO transactions should not update txnState local map (was: RO transations should not update txnState local map) > RO transactions should not update txnState local map > > > Key: IGNITE-21375 > URL: https://issues.apache.org/jira/browse/IGNITE-21375 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > h3. Motivation > On the one hand according to [~vpyatkov] updating txnstate within RO flow > brings us 20% performance drop, on the other hand RO transaction updates > corresponding state only for testing purposes, precisely in order to check > whether transaction rollback was called. See > org.apache.ignite.internal.tx.TxManager#pending for more details. > h3. Definition of Done > * Eliminate txnState local map updates within RO txn flow. > * Implement different mechanism for txn cleanup verification instead of > txnState local map based one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Description: h3. Motivation IGNITE-21375 is about removing txnState local map updates within RO txn flow because it brings us 20% performance drop. For RW transactions, it's however not possible, because such updates are required by the RW protocol. Thus, it seems reasonable to verify whether proposed VolatileTxStateMetaStorage is itself fast enough. h3. Definition of Done * Increase VolatileTxStateMetaStorag performance if it's possible. was: h3. Motivation IGNITE-21375 is about removing txnState local map update within RO txn flow becase it brings us 20% performance drop. For RW transactions it's however not possilbe to eliminate > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > > h3. Motivation > IGNITE-21375 is about removing txnState local map updates within RO txn flow > because it brings us 20% performance drop. For RW transactions, it's however > not possible, because such updates are required by the RW protocol. Thus, it > seems reasonable to verify whether proposed VolatileTxStateMetaStorage is > itself fast enough. > h3. Definition of Done > * Increase VolatileTxStateMetaStorag performance if it's possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Labels: PERFORMANCE Performance ignite-3 ignite3_performance performance performence (was: PERFORMANCE Performance ignite-3 ignite3_performance performance performence sql-performance) > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > > h3. Motivation > IGNITE-21375 is about removing txnState local map update within RO txn flow > becase it brings us 20% performance drop. For RW transactions it's however > not possilbe to eliminate -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Description: h3. Motivation IGNITE-21375 is about removing txnState local map update within RO txn flow becase it brings us 20% performance drop. For RW transactions it's however not possilbe to eliminate was: h3. Motivation IGNITE-21375 is about removing txnState local map update within RO txn flow becase it brings us 20% performance drop. For RW transactions it's however not possilbe to el > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence, sql-performance > > h3. Motivation > IGNITE-21375 is about removing txnState local map update within RO txn flow > becase it brings us 20% performance drop. For RW transactions it's however > not possilbe to eliminate -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Labels: PERFORMANCE Performance ignite-3 ignite3_performance performance performence sql-performance (was: PERFORMANCE Performance ignite-3 ignite3_performance performance performence) > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence, sql-performance > > h3. Motivation > IGNITE-21375 is about removing txnState local map update within RO txn flow > becase it brings us 20% performance drop. For RW transactions it's however > not possilbe to el -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Description: h3. Motivation IGNITE-21375 is about removing txnState local map update within RO txn flow becase it brings us 20% performance drop. For RW transactions it's however not possilbe to el > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > > h3. Motivation > IGNITE-21375 is about removing txnState local map update within RO txn flow > becase it brings us 20% performance drop. For RW transactions it's however > not possilbe to el -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Labels: PERFORMANCE Performance ignite-3 ignite3_performance performance performence (was: ignite-3 perform) > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Labels: ignite-3 perform (was: ) > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, perform > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
Alexander Lapin created IGNITE-21378: Summary: Ivestigate whether it's possible to make txnState local map updates faster Key: IGNITE-21378 URL: https://issues.apache.org/jira/browse/IGNITE-21378 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21378) Ivestigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21378: - Ignite Flags: (was: Docs Required,Release Notes Required) > Ivestigate whether it's possible to make txnState local map updates faster > -- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21375) RO transations should not update txnState local map
[ https://issues.apache.org/jira/browse/IGNITE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21375: - Description: h3. Motivation On the one hand according to [~vpyatkov] updating txnstate within RO flow brings us 20% performance drop, on the other hand RO transaction updates corresponding state only for testing purposes, precisely in order to check whether transaction rollback was called. See org.apache.ignite.internal.tx.TxManager#pending for more details. h3. Definition of Done * Eliminate txnState local map updates within RO txn flow. * Implement different mechanism for txn cleanup verification instead of txnState local map based one. > RO transations should not update txnState local map > --- > > Key: IGNITE-21375 > URL: https://issues.apache.org/jira/browse/IGNITE-21375 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > > h3. Motivation > On the one hand according to [~vpyatkov] updating txnstate within RO flow > brings us 20% performance drop, on the other hand RO transaction updates > corresponding state only for testing purposes, precisely in order to check > whether transaction rollback was called. See > org.apache.ignite.internal.tx.TxManager#pending for more details. > h3. Definition of Done > * Eliminate txnState local map updates within RO txn flow. > * Implement different mechanism for txn cleanup verification instead of > txnState local map based one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20491) .NET: Thin 3.0: Introduce configurable operation timeout
[ https://issues.apache.org/jira/browse/IGNITE-20491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811895#comment-17811895 ] Igor Sapego commented on IGNITE-20491: -- Looks good to me. > .NET: Thin 3.0: Introduce configurable operation timeout > > > Key: IGNITE-20491 > URL: https://issues.apache.org/jira/browse/IGNITE-20491 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have `SocketTimeout` which is only used for handshake and > heartbeats, which means we use it to check if the server and network are > responsive. > However, other operations (put, get, compute, etc) can take any amount of > time. > Investigate if a general operation timeout can be useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21017) Tracking RW transaction update operations
[ https://issues.apache.org/jira/browse/IGNITE-21017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811888#comment-17811888 ] Roman Puchkovskiy commented on IGNITE-21017: The patch looks good to me > Tracking RW transaction update operations > - > > Key: IGNITE-21017 > URL: https://issues.apache.org/jira/browse/IGNITE-21017 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > When creating a secondary index, there may be a situation where we do not > build an index for all records in the table. > This can happen when update operations of the RW transaction are performed at > the moment the index buildings begins. > The transaction has not yet seen the new index and therefore will not make > updates to it. And the index builder simply skipped them. Thus, we will not > have a consistent index. > To avoid this, we need to start building a secondary index of a specific > partition only when all update operations of RW transactions have completed > their operations strictly after the activation time of the index creation > event. > In this task, we will add tracking of update operations for RW transactions > for partition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21017) Tracking RW transaction update operations
[ https://issues.apache.org/jira/browse/IGNITE-21017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21017: --- Reviewer: Roman Puchkovskiy > Tracking RW transaction update operations > - > > Key: IGNITE-21017 > URL: https://issues.apache.org/jira/browse/IGNITE-21017 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > When creating a secondary index, there may be a situation where we do not > build an index for all records in the table. > This can happen when update operations of the RW transaction are performed at > the moment the index buildings begins. > The transaction has not yet seen the new index and therefore will not make > updates to it. And the index builder simply skipped them. Thus, we will not > have a consistent index. > To avoid this, we need to start building a secondary index of a specific > partition only when all update operations of RW transactions have completed > their operations strictly after the activation time of the index creation > event. > In this task, we will add tracking of update operations for RW transactions > for partition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21047) Sql. Avoid spamming execution tasks when possible
[
https://issues.apache.org/jira/browse/IGNITE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21047:
-
Assignee: Maksim Zhuravkov
> Sql. Avoid spamming execution tasks when possible
> -
>
> Key: IGNITE-21047
> URL: https://issues.apache.org/jira/browse/IGNITE-21047
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Need to revise all usages of
> {{org.apache.ignite.internal.sql.engine.exec.ExecutionContext#execute}} and
> check whether spawning a new task is legit in every particular case or it's
> better to do the work right now.
> For example, lets take a look at
> {{org.apache.ignite.internal.sql.engine.exec.rel.ScanNode#request}}:
>
> {code:java}
> @Override
> public void request(int rowsCnt) throws Exception {
> assert rowsCnt > 0 && requested == 0 : "rowsCnt=" + rowsCnt + ",
> requested=" + requested;
> checkState();
> requested = rowsCnt;
> if (!inLoop) {
> context().execute(this::push, this::onError);
> }
> }
> {code}
> in case of the very first request we will spawn a new task, but it would be
> better to drain the first batch of rows as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21377) Remove redundant tests
[
https://issues.apache.org/jira/browse/IGNITE-21377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-21377.
Resolution: Fixed
Thank you, merged into main: 7bfef7efded59c0c2890a0a83ea5a302881c8102
> Remove redundant tests
> --
>
> Key: IGNITE-21377
> URL: https://issues.apache.org/jira/browse/IGNITE-21377
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ItNotInitializedClusterRestTest}} has several tests that are duplicated in
> the {{{}ItClusterStateHttpServerFilterNotInitializedTest{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21377) Remove redundant tests
Vadim Pakhnushev created IGNITE-21377:
-
Summary: Remove redundant tests
Key: IGNITE-21377
URL: https://issues.apache.org/jira/browse/IGNITE-21377
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
{{ItNotInitializedClusterRestTest}} has several tests that are duplicated in
the {{{}ItClusterStateHttpServerFilterNotInitializedTest{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21376) Add the catalog version in which the index was created
[ https://issues.apache.org/jira/browse/IGNITE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21376: - Description: Add the catalog version in which the index was created into *org.apache.ignite.internal.catalog.descriptors.CatalogIndexDescriptor*. > Add the catalog version in which the index was created > -- > > Key: IGNITE-21376 > URL: https://issues.apache.org/jira/browse/IGNITE-21376 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add the catalog version in which the index was created into > *org.apache.ignite.internal.catalog.descriptors.CatalogIndexDescriptor*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21376) Add the catalog version in which the index was created
Kirill Tkalenko created IGNITE-21376: Summary: Add the catalog version in which the index was created Key: IGNITE-21376 URL: https://issues.apache.org/jira/browse/IGNITE-21376 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811868#comment-17811868
]
Anton Vinogradov commented on IGNITE-8801:
--
[~scottmf]
> what is the implication of making a cache TRANSACTIONAL as opposed to ATOMIC?
> IOW, why can't all caches be TRANSACTIONAL?
Simple answer is "tx caches are much slower than atomic" and should be used
only when special (distributed tx) guaranties are required.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21371) Fix ItDmlTest#testMerge
[ https://issues.apache.org/jira/browse/IGNITE-21371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-21371: -- Assignee: Kirill Sizov > Fix ItDmlTest#testMerge > --- > > Key: IGNITE-21371 > URL: https://issues.apache.org/jira/browse/IGNITE-21371 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > It was discovered that in > *org.apache.ignite.internal.sql.engine.ItDmlTest#testMerge*, queries *MERGE* > are executed in an implicit transaction that does not decrease the RW > transactions counter in > *org.apache.ignite.internal.index.IndexNodeFinishedRwTransactionsChecker#decrementRwTxCount*, > because of this, tests in which indexes are created can freeze. > If the test is turned on, > *org.apache.ignite.internal.sql.engine.ItDmlTest#rangeReadAndExclusiveInsert* > starts to fail. > h3. What is found out: > For an implicit RW transaction, *txCoordinatorId* may change because of this, > the counter cannot decrease. > This happens because the *org.apache.ignite.internal.tx.TxStateMeta* is > updated in > *org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#processRequest* > and changes *TxStateMeta#txCoordinatorId* to another, even if the > transaction is processed on the node that created it. > Presumably this is due to the fact that fragments of the transaction are > executed on different nodes; perhaps to fix it it will be enough to add > *txCoordinatorId* in the messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21375) RO transations should not update txnState local map
[ https://issues.apache.org/jira/browse/IGNITE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21375: - Ignite Flags: (was: Docs Required,Release Notes Required) > RO transations should not update txnState local map > --- > > Key: IGNITE-21375 > URL: https://issues.apache.org/jira/browse/IGNITE-21375 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21375) RO transations should not update txnState local map
[ https://issues.apache.org/jira/browse/IGNITE-21375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21375: - Labels: ignite-3 performance (was: ) > RO transations should not update txnState local map > --- > > Key: IGNITE-21375 > URL: https://issues.apache.org/jira/browse/IGNITE-21375 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, performance > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21375) RO transations should not update txnState local map
Alexander Lapin created IGNITE-21375: Summary: RO transations should not update txnState local map Key: IGNITE-21375 URL: https://issues.apache.org/jira/browse/IGNITE-21375 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21374) Cache delayDuration value
Roman Puchkovskiy created IGNITE-21374: -- Summary: Cache delayDuration value Key: IGNITE-21374 URL: https://issues.apache.org/jira/browse/IGNITE-21374 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 delayDuration value that is defined in the configuration is constant during cluster lifetime, but we get it on each schema sync. Its value should be cached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Description:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// plan:
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such query.
It is possible reduce plans that are guaranteed to produce no results to some
form of empty plans, so that the execution engine won't run them and return an
empty cursor instead.
was:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such query.
It is possible reduce plans that are guaranteed to produce no results to some
form of empty plans, so that the execution engine won't run them and return an
empty cursor instead.
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // plan:
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of empty plans, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Affects Version/s: 3.0.0-beta2
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of empty plans, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Description:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such query.
It is possible reduce plans that are guaranteed to produce no results to some
form of empty plans, so that the execution engine won't run them and return an
empty cursor instead.
was:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of empty plans, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Affects Version/s: (was: 3.0.0-beta2)
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of empty plans, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Labels: ignite-3 (was: )
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of empty plans, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21373) SQL. Get rid of the Ignite prefix in SQL operators.
Yury Gerzhedovich created IGNITE-21373: -- Summary: SQL. Get rid of the Ignite prefix in SQL operators. Key: IGNITE-21373 URL: https://issues.apache.org/jira/browse/IGNITE-21373 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Currently we have an Ignite prefix for all SQL statements for the text view of the plane (IgniteProject, IgniteNestedLoopJoin, IgniteTableScan, IgniteExchange, .). Let's get rid of the prefix. Since we are generating the name as a simple class name, we need to rework this part and introduce the ability to have a name independent of the class name for any operator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Description:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
was:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of an empty plan, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Summary: Sql. Do not execute queries that guaranteed to return no results.
(was: Sql. Do not execute queries that guaranteed to return none results.)
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // Query that never returns a result:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
> IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
> network=2.0], id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such a query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of an empty plan, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Description:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
was:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
network=2.0], id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such a query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of an empty plan, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return no results.
[
https://issues.apache.org/jira/browse/IGNITE-21372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21372:
--
Description:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// query that always returns no data:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
network=2.0], id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
was:
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// Query that never returns a result:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
network=2.0], id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
> Sql. Do not execute queries that guaranteed to return no results.
> -
>
> Key: IGNITE-21372
> URL: https://issues.apache.org/jira/browse/IGNITE-21372
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> {code:java}
> sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
> // query that always returns no data:
> sql("SELECT * FROM t2 WHERE id IS NULL");
> // Plan
> IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
> IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
> network=2.0], id = 28
> IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
> requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
> {code}
> Although the optimizer is able deduce that `id is NULL` is always false,
> since id is not nullable, and converted a predicate FALSE, the execution
> engine still runs such a query.
> It is possible reduce plans that are guaranteed to produce no results to some
> form of an empty plan, so that the execution engine won't run them and return
> an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21372) Sql. Do not execute queries that guaranteed to return none results.
Maksim Zhuravkov created IGNITE-21372:
-
Summary: Sql. Do not execute queries that guaranteed to return
none results.
Key: IGNITE-21372
URL: https://issues.apache.org/jira/browse/IGNITE-21372
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
{code:java}
sql("CREATE TABLE t2 (id INTEGER PRIMARY KEY, val INTEGER)");
// Query that never returns a result:
sql("SELECT * FROM t2 WHERE id IS NULL");
// Plan
IgniteExchange(distribution=[single]): rowcount = 2500.0, cumulative cost =
IgniteCost [rowCount=12500.0, cpu=42500.0, memory=0.0, io=0.0,
network=2.0], id = 28
IgniteTableScan(table=[[PUBLIC, T2]], tableId=[8], *filters=[false]*,
requiredColumns=[{0, 1}]): rowcount = 2500.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 25
{code}
Although the optimizer is able deduce that `id is NULL` is always false, since
id is not nullable, and converted a predicate FALSE, the execution engine still
runs such a query.
It is possible reduce plans that are guaranteed to produce no results to some
form of an empty plan, so that the execution engine won't run them and return
an empty cursor instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21181) Failure to resolve a primary replica after stopping a node
[
https://issues.apache.org/jira/browse/IGNITE-21181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-21181:
-
Assignee: Denis Chudov
> Failure to resolve a primary replica after stopping a node
> --
>
> Key: IGNITE-21181
> URL: https://issues.apache.org/jira/browse/IGNITE-21181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The scenario is that the cluster consists of 3 nodes (0, 1, 2). Primary
> replica of the sole partition is on node 0. Then node 0 is stopped and an
> attempt to do a put via node 2 is done. The partition still has majority, but
> the put results in the following:
>
> {code:java}
> org.apache.ignite.tx.TransactionException: IGN-REP-5
> TraceId:55c59c96-17d1-4efc-8e3c-cca81b8b41ad Failed to resolve the primary
> replica node [consistentId=itrst_ncisasiti_0]
>
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$69(InternalTableImpl.java:1749)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlist(InternalTableImpl.java:1739)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistWithRetry(InternalTableImpl.java:480)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistInTx(InternalTableImpl.java:301)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.upsert(InternalTableImpl.java:965)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$10(KeyValueViewImpl.java:196)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:111)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:111)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:193)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:185)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:257)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:253)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(ItTableRaftSnapshotsTest.java:473){code}
>
> This can be reproduced using
> ItTableRaftSnapshotsTest#nodeCanInstallSnapshotsAfterSnapshotInstalledToIt().
> The reason is that, according to the test, the leader of partition group is
> transferred on node 0, which means that this node most probably will be
> selected as primary, and after that the node 0 is stopped, and then the
> transaction is started. Node 0 is still a leaseholder in the current time
> interval, but it's already left the topology.
> We can fix the test to make it await the new primary, which would be present
> in the cluster, or make the restries on the very first transactional request.
> In the case of latter, we need to ensure that the request is actually first
> and single, no other request in any parallel thread was sent, otherwise we
> cant retry the request on another primary .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20377) Rename term to enlistmentConsistencyToken wherever primary replica is used
[ https://issues.apache.org/jira/browse/IGNITE-20377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-20377: -- Assignee: Kirill Sizov > Rename term to enlistmentConsistencyToken wherever primary replica is used > -- > > Key: IGNITE-20377 > URL: https://issues.apache.org/jira/browse/IGNITE-20377 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Within IGNITE-18856 primary replica calculation was switched from raft leader > collocation to primary replicas provided by placement driver service, however > within replica requests, exceptions, tx context naming term still used > (despite the fact that instead real term it holds lease.startTime). So, it's > required to rename term wherever possible. > h3. Definition of Done > * Term should be renamed to enlistment consistency token or similar wherever > leases are used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
