[jira] [Created] (IGNITE-21233) Fix broken compilation in main after Error Codes changes
Dmitrii Zabotlin created IGNITE-21233: - Summary: Fix broken compilation in main after Error Codes changes Key: IGNITE-21233 URL: https://issues.apache.org/jira/browse/IGNITE-21233 Project: Ignite Issue Type: Bug Reporter: Dmitrii Zabotlin Assignee: Dmitrii Zabotlin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20974) It seems a row has been skipped by the removal operation
[
https://issues.apache.org/jira/browse/IGNITE-20974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov resolved IGNITE-20974.
Resolution: Duplicate
> It seems a row has been skipped by the removal operation
>
>
> Key: IGNITE-20974
> URL: https://issues.apache.org/jira/browse/IGNITE-20974
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, ignite-3
> Attachments: _Integration_Tests_Module_Table_17003.log.zip
>
>
> h3. Motivation
> This issue has happened in TC, but it is very rare, and it is related to a
> multi-node cluster only (TC log was attached). Look at the exception for
> ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
> {noformat}
> 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.AssertNull.failNotNull(AssertNull.java:50)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
> at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> {noformat}
> The assertion failed exception is here (in line 6):
> {code:title=TxAbstractTest.java}
> view.deleteAll(tx, keys);
> for (Tuple key : keys) {
> Tuple entry = view.get(tx, key);
> assertNull(entry);
> }
> {code}
> h3. Implementation notes
> Check that the result of the _deleteAll_ operation is an empty collection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21134) Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
[
https://issues.apache.org/jira/browse/IGNITE-21134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-21134:
---
Assignee: Evgeny Stanilovsky
> Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
> --
>
> Key: IGNITE-21134
> URL: https://issues.apache.org/jira/browse/IGNITE-21134
> Project: Ignite
> Issue Type: Bug
> Components: clients, sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> As described in ANSI99 specification, functions UPPER and LOWER must return
> NULL values for NULL argument:
>
> ??5) If is specified, then:??
> ?? .. b) if S is the null value, then the result of the is the null
> value.??
> In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error
> is shown instead:
> {code:sql}
> sql-cli> SELECT UPPER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT LOWER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
> Unknown error
> Unsupported Column type NULL{code}
> {*}NOTE{*}: Most probably, it may be caused by client module, not sql module
> because a text of error is located in client-common module:
> {code:java}
> $ grep -r 'Unsupported Column type' modules/*/src/main
> modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
> throw new IllegalArgumentException("Unsupported Column type "
> + columnType);
> {code}
> And when I add the following assertion to some test in ItFunctionsTest, it
> passes:
> {code:java}
> assertQuery("SELECT LOWER(NULL)").returns(null).check();
> {code}
> Previous AI3 versions allowed using NULL values in UPPER and LOWER functions,
> hence it's a degradation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-20974) It seems a row has been skipped by the removal operation
[ https://issues.apache.org/jira/browse/IGNITE-20974 ]
Vladislav Pyatkov deleted comment on IGNITE-20974:
was (Author: v.pyatkov):
This issue looks like the issue with incorrect RO transaction read timesatmp
calculation IGNITE-21016.
> It seems a row has been skipped by the removal operation
>
>
> Key: IGNITE-20974
> URL: https://issues.apache.org/jira/browse/IGNITE-20974
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, ignite-3
> Attachments: _Integration_Tests_Module_Table_17003.log.zip
>
>
> h3. Motivation
> This issue has happened in TC, but it is very rare, and it is related to a
> multi-node cluster only (TC log was attached). Look at the exception for
> ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
> {noformat}
> 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.AssertNull.failNotNull(AssertNull.java:50)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
> at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> {noformat}
> The assertion failed exception is here (in line 6):
> {code:title=TxAbstractTest.java}
> view.deleteAll(tx, keys);
> for (Tuple key : keys) {
> Tuple entry = view.get(tx, key);
> assertNull(entry);
> }
> {code}
> h3. Implementation notes
> Check that the result of the _deleteAll_ operation is an empty collection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20974) It seems a row has been skipped by the removal operation
[
https://issues.apache.org/jira/browse/IGNITE-20974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805413#comment-17805413
]
Vladislav Pyatkov commented on IGNITE-20974:
The test has never failed in the entire available history. I suspect the issue
was already fixed when we fixed the choice to read transaction timestamp
IGNITE-21016.
> It seems a row has been skipped by the removal operation
>
>
> Key: IGNITE-20974
> URL: https://issues.apache.org/jira/browse/IGNITE-20974
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, ignite-3
> Attachments: _Integration_Tests_Module_Table_17003.log.zip
>
>
> h3. Motivation
> This issue has happened in TC, but it is very rare, and it is related to a
> multi-node cluster only (TC log was attached). Look at the exception for
> ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
> {noformat}
> 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.AssertNull.failNotNull(AssertNull.java:50)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
> at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> {noformat}
> The assertion failed exception is here (in line 6):
> {code:title=TxAbstractTest.java}
> view.deleteAll(tx, keys);
> for (Tuple key : keys) {
> Tuple entry = view.get(tx, key);
> assertNull(entry);
> }
> {code}
> h3. Implementation notes
> Check that the result of the _deleteAll_ operation is an empty collection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21232) Fail sending a message if resolved sender's destination node ID differs from target node ID
[ https://issues.apache.org/jira/browse/IGNITE-21232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21232: --- Description: # Methods of MessagingService that accept ClusterNode for recipient must fail the send/invocation attempt (with same exception which is used when the target node has gone) if the resolved sender's destination node ID is different from the node ID specified in the ClusterNode for recipient. # Methods that accept consistentId should behave in the same way: they should just resolve the ClusterNode by the provided consistentId and then proceed as in item 1 > Fail sending a message if resolved sender's destination node ID differs from > target node ID > --- > > Key: IGNITE-21232 > URL: https://issues.apache.org/jira/browse/IGNITE-21232 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > # Methods of MessagingService that accept ClusterNode for recipient must fail > the send/invocation attempt (with same exception which is used when the > target node has gone) if the resolved sender's destination node ID is > different from the node ID specified in the ClusterNode for recipient. > # Methods that accept consistentId should behave in the same way: they > should just resolve the ClusterNode by the provided consistentId and then > proceed as in item 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21232) Fail sending a message if resolved sender's destination node ID differs from target node ID
Roman Puchkovskiy created IGNITE-21232: -- Summary: Fail sending a message if resolved sender's destination node ID differs from target node ID Key: IGNITE-21232 URL: https://issues.apache.org/jira/browse/IGNITE-21232 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21192) SchemaManager operation should not block MetaStorage watches
[ https://issues.apache.org/jira/browse/IGNITE-21192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-21192. Resolution: Won't Do Irrelevant after IGNITE-21205 has been implemented > SchemaManager operation should not block MetaStorage watches > > > Key: IGNITE-21192 > URL: https://issues.apache.org/jira/browse/IGNITE-21192 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > SchemaManager writes table's schema version to the MetaStorage as soon as the > table is created/altered in the Catalog. The Catalog events are triggered by > the MetaStorage events handling in MetaStorage watches. The future for > writing to the MetaStorage (when saving the table schema version) is returned > from the event handler by SchemaManager, so, effectively, the write to the MS > blocks finishing processing of MS events, which in turn might block leases > and schema sync, causing problems. > Including the writing part to the future of handling the original watch event > if handy because this gives us a pretty strong guarantee: if a Catalog > version is active on the node, then SchemaManager's table schemas > corresponding to this version are also available on the node. > Currently, we make sure that a node can see a tuple written in a schema > version only after the node sees the corresopnding Catalog version. We can > extend this by also waiting for SchemaManager's table version corresponding > to the Catalog version to be available on the node. Having this, we will be > able to drop the requirement for the future chaining. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21190) SchemaManager should not rely on system-wide applied revision
[ https://issues.apache.org/jira/browse/IGNITE-21190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-21190. Resolution: Won't Do Irrelavant after IGNITE-21205 has been implemented > SchemaManager should not rely on system-wide applied revision > - > > Key: IGNITE-21190 > URL: https://issues.apache.org/jira/browse/IGNITE-21190 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, SchemaManager uses global MetaStorage's applied revision to track > which revisions were not accounted for yet. The global applied revision > mechanism will likely be removed; also, if a node is down for some time, the > global applied revision might make a leap, and we'll not be able to see how > many revisions were skipped. > SchemaManager should have its own 'applied revision' or 'applied Catalog > version' stored in the Vault. When doing a startup recovery, it should use it > to process the Catalog versions that might be missed while being offline. > Also, current implementation has a bug: if a node is not a MetaStorage > leader, it might happen that it receives an event about a table schema change > before the previous table schema (saved by SchemaManager) is replicated to > this node, and the current code relies on it already being available locally. > This bug has to be fixed (probably, as a by-product of implementing this > feature). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21193) Fail message send futures when the receiver leaves the physical topology
[ https://issues.apache.org/jira/browse/IGNITE-21193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-21193. Resolution: Fixed > Fail message send futures when the receiver leaves the physical topology > > > Key: IGNITE-21193 > URL: https://issues.apache.org/jira/browse/IGNITE-21193 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > After IGNITE-16947 gets implemented, we'll keep the futures in a queue. They > should be failed if the receiver leaves the Physical Topology before > acknowledging the corresponding messages (with a proper exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21193) Fail message send futures when the receiver leaves the physical topology
[ https://issues.apache.org/jira/browse/IGNITE-21193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-21193: -- Assignee: Roman Puchkovskiy > Fail message send futures when the receiver leaves the physical topology > > > Key: IGNITE-21193 > URL: https://issues.apache.org/jira/browse/IGNITE-21193 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > After IGNITE-16947 gets implemented, we'll keep the futures in a queue. They > should be failed if the receiver leaves the Physical Topology before > acknowledging the corresponding messages (with a proper exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21193) Fail message send futures when the receiver leaves the physical topology
[ https://issues.apache.org/jira/browse/IGNITE-21193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-21193: -- Assignee: (was: Roman Puchkovskiy) > Fail message send futures when the receiver leaves the physical topology > > > Key: IGNITE-21193 > URL: https://issues.apache.org/jira/browse/IGNITE-21193 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > After IGNITE-16947 gets implemented, we'll keep the futures in a queue. They > should be failed if the receiver leaves the Physical Topology before > acknowledging the corresponding messages (with a proper exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20809) Sql. NoSuchMethodException with substring.
[
https://issues.apache.org/jira/browse/IGNITE-20809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-20809:
---
Assignee: Evgeny Stanilovsky
> Sql. NoSuchMethodException with substring.
> --
>
> Key: IGNITE-20809
> URL: https://issues.apache.org/jira/browse/IGNITE-20809
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> sql(String.format("SELECT substring((SELECT 'a'), 1, %d + 1)",
> Long.MAX_VALUE));{code}
>
> throws inner implementation exception:
> {code:java}
> Caused by: java.lang.NoSuchMethodException:
> org.apache.calcite.runtime.SqlFunctions.substring(java.lang.String, int, long)
> at java.base/java.lang.Class.getMethod(Class.java:2108)
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:658){code}
> Seems we will obtain the same exceptions with all not implemented inner
> functions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805258#comment-17805258
]
Dmitrii Kriukov commented on IGNITE-21185:
--
[~alex_pl] good point
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20848) Management REST API for Compute
[
https://issues.apache.org/jira/browse/IGNITE-20848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-20848:
--
Assignee: Ivan Gagarkin
> Management REST API for Compute
>
>
> Key: IGNITE-20848
> URL: https://issues.apache.org/jira/browse/IGNITE-20848
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Mikhail Pochatkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> POST /management/v1/compute/priority
> //Change priority for job
> //Body with job is and new priority
>
> GET /management/v1/compute/jobs
> //List of all job's statuses
>
> GET /management/v1/compute/jobs/\{id}
> //Job status for specified id
>
> DELETE /management/v1/compute/cancel/\{id}
> //Cancel job for specified id
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21064) Refactor authentication naming and enum in Thin Client for clarity
[
https://issues.apache.org/jira/browse/IGNITE-21064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin reassigned IGNITE-21064:
--
Assignee: Ivan Gagarkin
> Refactor authentication naming and enum in Thin Client for clarity
> --
>
> Key: IGNITE-21064
> URL: https://issues.apache.org/jira/browse/IGNITE-21064
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Ivan Gagarkin
>Assignee: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the Thin Client utilizes
> {{org.apache.ignite.security.AuthenticationType}} to specify the
> authentication method during the handshake process. This approach can be
> confusing due to its interaction with the type of authentication defined in
> the configuration. To resolve this, we propose creating a separate
> enumeration specifically for the client. Additionally, the 'BASIC'
> authentication type should be renamed to 'PASSWORD' for clearer understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18617) Clear the map of tx cleanup ready futures on tx state vacuum
[ https://issues.apache.org/jira/browse/IGNITE-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18617: - Epic Link: IGNITE-21221 (was: IGNITE-21174) > Clear the map of tx cleanup ready futures on tx state vacuum > > > Key: IGNITE-18617 > URL: https://issues.apache.org/jira/browse/IGNITE-18617 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > The map PartitionReplicaListener#txCleanupReadyFutures is not cleared > anywhere. It should be cleared in the same way as tx states storage (which is > not defined yet). > TBD. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21215) Catalog API should allow renaming tables
[
https://issues.apache.org/jira/browse/IGNITE-21215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21215:
-
Description:
Implementation details:
# Add Catalog commands for renaming a table;
# Add corresponding {{UpdateEntry}} implementations;
# Add events and event types, if needed.
was:
Implementation details:
# Add Catalog commands for renaming a table and an index;
# Add corresponding {{UpdateEntry}} implementations;
# Add events and event types, if needed.
> Catalog API should allow renaming tables
>
>
> Key: IGNITE-21215
> URL: https://issues.apache.org/jira/browse/IGNITE-21215
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Implementation details:
> # Add Catalog commands for renaming a table;
> # Add corresponding {{UpdateEntry}} implementations;
> # Add events and event types, if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21215) Catalog API should allow renaming tables
[
https://issues.apache.org/jira/browse/IGNITE-21215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21215:
-
Summary: Catalog API should allow renaming tables (was: Catalog API should
allow renaming tables and indices)
> Catalog API should allow renaming tables
>
>
> Key: IGNITE-21215
> URL: https://issues.apache.org/jira/browse/IGNITE-21215
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Implementation details:
> # Add Catalog commands for renaming a table and an index;
> # Add corresponding {{UpdateEntry}} implementations;
> # Add events and event types, if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21019) Sql. Improve conversion to BinaryRow in UpdatableTableImpl
[
https://issues.apache.org/jira/browse/IGNITE-21019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21019:
-
Assignee: Maksim Zhuravkov
> Sql. Improve conversion to BinaryRow in UpdatableTableImpl
> --
>
> Key: IGNITE-21019
> URL: https://issues.apache.org/jira/browse/IGNITE-21019
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> As for now, {{UpdatableTableImpl}} uses {{RowAssembler}} to re-assemble row
> prior to send it to the table. The problem here is this is not very efficient
> because of number of reasons. First, the most simple constructor of
> {{RowAssembler}} is used, this causes tuple builder to preallocate 4kb of
> buffer, which sometimes is too much. Second, usage of {{RowAssembler}}
> implies double (de-)serialization since every field should be read from
> source row and write back to target tuple.
> Given that sql row now natively supports to binary tuple conversion,
> depending on the schema of a table we may reuse that binary tuple or
> reshuffle fields avoiding deserialisation by reading raw bytes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20827) Sql. Remove nullBound placeholder.
[ https://issues.apache.org/jira/browse/IGNITE-20827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20827: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Remove nullBound placeholder. > --- > > Key: IGNITE-20827 > URL: https://issues.apache.org/jira/browse/IGNITE-20827 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Konstantin Orlov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > NullBound placeholder value (BinaryRowConverter::NULL_BOUND) is used to > support for IS NULL / IS NOT DISTINCT FROM operators in search bounds. > Let's remove it in favour of implementaion that does not rely on magic values > to implement aforementated operators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-21001:
---
Assignee: Mikhail Petrov (was: Nikita Amelchev)
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
>
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Fix Version/s: 2.17
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
>
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805127#comment-17805127 ] Yury Gerzhedovich commented on IGNITE-21203: [~korlov] LGTM, thanks > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21231) HeapLockManager#locks method do not provide all acuired locks
[
https://issues.apache.org/jira/browse/IGNITE-21231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21231:
---
Summary: HeapLockManager#locks method do not provide all acuired locks
(was: HeapLockManager#locks method do not provide all acuired locks.)
> HeapLockManager#locks method do not provide all acuired locks
> -
>
> Key: IGNITE-21231
> URL: https://issues.apache.org/jira/browse/IGNITE-21231
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> If a lock key does not use the context id (_LockKey#contextId_ is _null_), it
> does not appear in the iterator. Here is a test that demonstrates incorrect
> behavior:
> {code:title=AbstractLockManagerTest.java}
> @Test
> public void simpleTest() {
> UUID txId1 = TestTransactionIds.newTransactionId();
> LockKey key = new LockKey(0);
> lockManager.acquire(txId1, key, S).join();
> assertTrue(lockManager.locks(txId1).hasNext());
> }
> {code}
> h3. Definition of done
> Despite the fact that the method is used only in tests, it has to work
> correctly. All locks should be in the lock iterator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21231) HeapLockManager#locks method do not provide all acuired locks.
[
https://issues.apache.org/jira/browse/IGNITE-21231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21231:
---
Description:
h3. Motivation
If a lock key does not use the context id (_LockKey#contextId_ is _null_), it
does not appear in the iterator. Here is a test that demonstrates incorrect
behavior:
{code:title=AbstractLockManagerTest.java}
@Test
public void simpleTest() {
UUID txId1 = TestTransactionIds.newTransactionId();
LockKey key = new LockKey(0);
lockManager.acquire(txId1, key, S).join();
assertTrue(lockManager.locks(txId1).hasNext());
}
{code}
h3. Definition of done
Despite the fact that the method is used only in tests, it has to work
correctly. All locks should be in the lock iterator.
was:
h3. Motivation
If a lock key does not use the context id (LockKey#contextId is null), it does
not appear in the iterator. Here is a test that demonstrates incorrect behavior:
{code:title=AbstractLockManagerTest.java}
@Test
public void simpleTest() {
UUID txId1 = TestTransactionIds.newTransactionId();
LockKey key = new LockKey(0);
lockManager.acquire(txId1, key, S).join();
assertTrue(lockManager.locks(txId1).hasNext());
}
{code}
h3. Definition of done
Despite the fact that the method is used only in tests, it has to work
correctly. All locks should be in the lock iterator.
> HeapLockManager#locks method do not provide all acuired locks.
> --
>
> Key: IGNITE-21231
> URL: https://issues.apache.org/jira/browse/IGNITE-21231
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> If a lock key does not use the context id (_LockKey#contextId_ is _null_), it
> does not appear in the iterator. Here is a test that demonstrates incorrect
> behavior:
> {code:title=AbstractLockManagerTest.java}
> @Test
> public void simpleTest() {
> UUID txId1 = TestTransactionIds.newTransactionId();
> LockKey key = new LockKey(0);
> lockManager.acquire(txId1, key, S).join();
> assertTrue(lockManager.locks(txId1).hasNext());
> }
> {code}
> h3. Definition of done
> Despite the fact that the method is used only in tests, it has to work
> correctly. All locks should be in the lock iterator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21231) HeapLockManager#locks method do not provide all acuired locks.
Vladislav Pyatkov created IGNITE-21231:
--
Summary: HeapLockManager#locks method do not provide all acuired
locks.
Key: IGNITE-21231
URL: https://issues.apache.org/jira/browse/IGNITE-21231
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
h3. Motivation
If a lock key does not use the context id (LockKey#contextId is null), it does
not appear in the iterator. Here is a test that demonstrates incorrect behavior:
{code:title=AbstractLockManagerTest.java}
@Test
public void simpleTest() {
UUID txId1 = TestTransactionIds.newTransactionId();
LockKey key = new LockKey(0);
lockManager.acquire(txId1, key, S).join();
assertTrue(lockManager.locks(txId1).hasNext());
}
{code}
h3. Definition of done
Despite the fact that the method is used only in tests, it has to work
correctly. All locks should be in the lock iterator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21208) Sql. DEFAULT expression with NULL value processed unexpectedly
[
https://issues.apache.org/jira/browse/IGNITE-21208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-21208.
-
Release Note: implemented in calcite side
Resolution: Implemented
> Sql. DEFAULT expression with NULL value processed unexpectedly
> --
>
> Key: IGNITE-21208
> URL: https://issues.apache.org/jira/browse/IGNITE-21208
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Correct processing for NULL consistent expressions require additional
> overriding of IgniteSqlToRelConvertor#convertValues, seems we can avoid it.
> Expressions need to be passed without such overriding method:
> {noformat}
> create table t (id int, c int DEFAULT null);
> insert into t(id, c) values(1, DEFAULT);
> insert into t(id) values(2);
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21230) Improve serialisation of catalog commands
[ https://issues.apache.org/jira/browse/IGNITE-21230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-21230: -- Description: Currently, catalog uses java's built-in serialisation in order to persists descriptors and update entries. Although it is most simple way to address conversion of POJO to byte array, the built-in serialisation is not efficient in terms of occupied space. Given that catalog may contain thousands and thousands of objects, it may result in increased load on a metastorage. To address this issue, let's introduce custom serialisation format for catalog's descriptors and update entries. NB: we should keep in mind that descriptors may evolve over time, thus we should consider support of versioning for descriptors was: Currently, catalog uses java built in serialisation in order to persists descriptors and update entries. Although it is most simple way to address conversion of POJO to byte array, the built in serialisation is not efficient in terms of occupied space. Given that catalog may contain thousands and thousands of objects, it may result in increased load on a metastorage. To address this issue, let's introduce custom serialisation format for catalog's descriptors and update entries. NB: we should keep in mind that descriptors may evolve over time, thus we should consider support of versioning for descriptors > Improve serialisation of catalog commands > - > > Key: IGNITE-21230 > URL: https://issues.apache.org/jira/browse/IGNITE-21230 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Currently, catalog uses java's built-in serialisation in order to persists > descriptors and update entries. Although it is most simple way to address > conversion of POJO to byte array, the built-in serialisation is not efficient > in terms of occupied space. Given that catalog may contain thousands and > thousands of objects, it may result in increased load on a metastorage. > To address this issue, let's introduce custom serialisation format for > catalog's descriptors and update entries. > NB: we should keep in mind that descriptors may evolve over time, thus we > should consider support of versioning for descriptors -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-21165:
-
Assignee: Vladimir Steshin
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-21165:
--
Fix Version/s: 2.17
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[ https://issues.apache.org/jira/browse/IGNITE-21165 ]
Vladimir Steshin deleted comment on IGNITE-21165:
---
was (Author: vladsz83):
[~ptupitsyn], could you take a look please? The timeouts have gone.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21229) Close TxStateStorage.scan() cursors
[ https://issues.apache.org/jira/browse/IGNITE-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21229: - Epic Link: IGNITE-21221 > Close TxStateStorage.scan() cursors > --- > > Key: IGNITE-21229 > URL: https://issues.apache.org/jira/browse/IGNITE-21229 > 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-21229) Close TxStateStorage.scan() cursors
[ https://issues.apache.org/jira/browse/IGNITE-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21229: - Labels: ignite-3 (was: ) > Close TxStateStorage.scan() cursors > --- > > Key: IGNITE-21229 > URL: https://issues.apache.org/jira/browse/IGNITE-21229 > 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-21229) Close TxStateStorage.scan() cursors
Alexander Lapin created IGNITE-21229: Summary: Close TxStateStorage.scan() cursors Key: IGNITE-21229 URL: https://issues.apache.org/jira/browse/IGNITE-21229 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21229) Close TxStateStorage.scan() cursors
[ https://issues.apache.org/jira/browse/IGNITE-21229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21229: - Ignite Flags: (was: Docs Required,Release Notes Required) > Close TxStateStorage.scan() cursors > --- > > Key: IGNITE-21229 > URL: https://issues.apache.org/jira/browse/IGNITE-21229 > 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-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#destriyProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We should wait until _java.lang.Process_ completely stops.
was:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
It looks like this issue happens on JDK8 only. And only on Linux.
_ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
_PlatformProcessUtils#startProcess()_ and stops with
_PlatformProcessUtils#stopProcess()_. On Windows, additional
{code:java}
serverProc.KillProcessTree();
{code}
is applied.
We should wait until _java.lang.Process_ completely stops.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#destriyProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20207) Improve the error handling
[ https://issues.apache.org/jira/browse/IGNITE-20207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20207: --- Description: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. In case of any error the transfer should be started from scratch. We need to define cases when Ignite can provide recovery and implement this functionality. (was: The current implementation of org.apache.ignite.internal.network.file.FileTransferService doesn't provide recovery functionality. Any error during file transfer leads to repeating the transfer from scratch. We need to define cases when Ignite can provide recovery and implement this functionality. ) > Improve the error handling > -- > > Key: IGNITE-20207 > URL: https://issues.apache.org/jira/browse/IGNITE-20207 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Gagarkin >Priority: Major > Labels: ignite-3 > > The current implementation of > org.apache.ignite.internal.network.file.FileTransferService doesn't provide > recovery functionality. In case of any error the transfer should be started > from scratch. We need to define cases when Ignite can provide recovery and > implement this functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21228) Data not available thtough JDBC after inserting using KV for a while
[ https://issues.apache.org/jira/browse/IGNITE-21228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805081#comment-17805081 ] Yury Gerzhedovich commented on IGNITE-21228: [~Berkov] could you confirm that the rows available through java API in the same time? > Data not available thtough JDBC after inserting using KV for a while > > > Key: IGNITE-21228 > URL: https://issues.apache.org/jira/browse/IGNITE-21228 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > # Create table using java API > # Insert 100 rows using sync KV java API > # Connect using JDBC and try to select inserted data > Expected result: all rows available > Actual result: no rows available for a few hundreds of milliseconds > (700-1000ms on my laptop). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21140) Ignite 3 Disaster Recovery
[ https://issues.apache.org/jira/browse/IGNITE-21140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-21140: --- Description: This epic is related to issues that may happen with users when part of their data becomes unavailable for some reasons, like "node is lost", or "part of the storage is lost", etc. > Ignite 3 Disaster Recovery > -- > > Key: IGNITE-21140 > URL: https://issues.apache.org/jira/browse/IGNITE-21140 > Project: Ignite > Issue Type: Epic >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > This epic is related to issues that may happen with users when part of their > data becomes unavailable for some reasons, like "node is lost", or "part of > the storage is lost", etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Description: Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. It is proposed to not consider classes that are not in org.apache.ignite package as system. was:Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. > It is proposed to not consider classes that are not in org.apache.ignite > package as system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20795) Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes.
[ https://issues.apache.org/jira/browse/IGNITE-20795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20795: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes. > > > Key: IGNITE-20795 > URL: https://issues.apache.org/jira/browse/IGNITE-20795 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > IgniteTableFunctionScan implements SourceAwareIgniteRel but returns hardcoded > sourceId that is equal to -1, because QuerySplitter does not visit nodes of > this type. > Update QuerySpliiter to visit IgniteTableFunctionScan and fix this behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Fix Version/s: 2.17 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Affects Version/s: 2.16 2.15 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Component/s: security > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Ignite Flags: (was: Docs Required,Release Notes Required) > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21216. - Resolution: Fixed > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805069#comment-17805069 ] Konstantin Orlov commented on IGNITE-21203: --- [~jooger], do a review please > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805070#comment-17805070 ] Mikhail Petrov commented on IGNITE-21216: - [~NSAmelchev] Thank you for the review. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-21203: -- Ignite Flags: (was: Docs Required,Release Notes Required) > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-21203: -- Fix Version/s: 3.0.0-beta2 > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[
https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805067#comment-17805067
]
Ignite TC Bot commented on IGNITE-21216:
{panel:title=Branch: [pull/11167/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11167/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7696709&buildTypeId=IgniteTests24Java8_RunAll]
> Do not consider tasks that are not in org.apache.ignite package as system
> -
>
> Key: IGNITE-21216
> URL: https://issues.apache.org/jira/browse/IGNITE-21216
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Check https://github.com/apache/ignite/issues/10907 for more detailed
> description of the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21219) Write memory leak tests
[ https://issues.apache.org/jira/browse/IGNITE-21219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-21219: --- Description: Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. Important note: the simulation of leaving and joining the cluster of several nodes (candidates, workers) should be done as well. was:Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. > Write memory leak tests > --- > > Key: IGNITE-21219 > URL: https://issues.apache.org/jira/browse/IGNITE-21219 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Compute jobs handling logic is getting harder to track every reference we > have. It seems like we can easily introduce a memory leak. I wonder if we > have some microbenchmarks that prove the absence of memory leak in the > compute component. > Important note: the simulation of leaving and joining the cluster of several > nodes (candidates, workers) should be done as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805032#comment-17805032
]
Aleksey Plekhanov commented on IGNITE-21185:
[~dkryukov] {{name()}} method returns interned string (see
[https://github.com/apache/ignite/blob/master/modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/trait/DistributionFunction.java#L59]),
so it's safe to use {{==}} operator here.
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Epic Link: IGNITE-21221 (was: IGNITE-21174)
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
>
> All in all, seems that it's required to substitute
>
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));{code}
> with
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable)
> -> {
> releaseTxLocks(txId);
> try {
> closeAllTransactionCursors(txId);
> } catch (Exception e) {
> LOG.warn("Unable to close cursor on primary
> replica expiration", e);
> }
> }));{code}
> Tests are trickey though.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17666) Scan subscription cancel does not close a server side cursor
[ https://issues.apache.org/jira/browse/IGNITE-17666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17666: - Epic Link: IGNITE-21221 (was: IGNITE-21174) > Scan subscription cancel does not close a server side cursor > > > Key: IGNITE-17666 > URL: https://issues.apache.org/jira/browse/IGNITE-17666 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Read-only transactions start a scan operation and save transaction cursors on > the replica side. The cursors stay on the server until they are closed. > Read-only transactions finish locally and do not notify all replicas of the > transaction. > h3. Definition of done > # Enlist node to RO transaction. > # Prohibit adding operations to the read-only transaction after the > transaction is finished. > # Send the finish transaction request to all enlisted nodes to close cursors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21228) Data not available thtough JDBC after inserting using KV for a while
Alexander Belyak created IGNITE-21228: - Summary: Data not available thtough JDBC after inserting using KV for a while Key: IGNITE-21228 URL: https://issues.apache.org/jira/browse/IGNITE-21228 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 3.0 Reporter: Alexander Belyak # Create table using java API # Insert 100 rows using sync KV java API # Connect using JDBC and try to select inserted data Expected result: all rows available Actual result: no rows available for a few hundreds of milliseconds (700-1000ms on my laptop). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20745) TableManager.tableAsync(int tableId) is slowing down thin clients
[ https://issues.apache.org/jira/browse/IGNITE-20745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805011#comment-17805011 ] Igor Sapego commented on IGNITE-20745: -- The core problem is not solved by the suggested edit. > TableManager.tableAsync(int tableId) is slowing down thin clients > - > > Key: IGNITE-20745 > URL: https://issues.apache.org/jira/browse/IGNITE-20745 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ItThinClientPutGetBenchmark.java > > Time Spent: 10m > Remaining Estimate: 0h > > Performance difference between embedded and client modes is affected > considerably by the call to *IgniteTablesInternal#tableAsync(int id)*. This > call has to be performed on every individual table operation. > We should make it as fast as possible. Something like a dictionary lookup + > quick check for deleted table. > ||Part||Duration, us|| > |Network & msgpack|19.30| > |Get table|14.29| > |Get tuple & serialize|12.86| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20745) TableManager.tableAsync(int tableId) is slowing down thin clients
[
https://issues.apache.org/jira/browse/IGNITE-20745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805008#comment-17805008
]
Igor Sapego edited comment on IGNITE-20745 at 1/10/24 8:29 AM:
---
Checked the hypothesis.
{noformat}
Throughput without fix (ops/sec): 4425.4
Throughput with fix (ops/sec):4589.5
{noformat}
was (Author: isapego):
Checked the hypothesis.
{nocode}
Throughput without fix (ops/sec): 4425.4
Throughput with fix (ops/sec):4589.5
{nocode}
> TableManager.tableAsync(int tableId) is slowing down thin clients
> -
>
> Key: IGNITE-20745
> URL: https://issues.apache.org/jira/browse/IGNITE-20745
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ItThinClientPutGetBenchmark.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Performance difference between embedded and client modes is affected
> considerably by the call to *IgniteTablesInternal#tableAsync(int id)*. This
> call has to be performed on every individual table operation.
> We should make it as fast as possible. Something like a dictionary lookup +
> quick check for deleted table.
> ||Part||Duration, us||
> |Network & msgpack|19.30|
> |Get table|14.29|
> |Get tuple & serialize|12.86|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20745) TableManager.tableAsync(int tableId) is slowing down thin clients
[
https://issues.apache.org/jira/browse/IGNITE-20745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805008#comment-17805008
]
Igor Sapego commented on IGNITE-20745:
--
Checked the hypothesis.
{nocode}
Throughput without fix (ops/sec): 4425.4
Throughput with fix (ops/sec):4589.5
{nocode}
> TableManager.tableAsync(int tableId) is slowing down thin clients
> -
>
> Key: IGNITE-20745
> URL: https://issues.apache.org/jira/browse/IGNITE-20745
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ItThinClientPutGetBenchmark.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Performance difference between embedded and client modes is affected
> considerably by the call to *IgniteTablesInternal#tableAsync(int id)*. This
> call has to be performed on every individual table operation.
> We should make it as fast as possible. Something like a dictionary lookup +
> quick check for deleted table.
> ||Part||Duration, us||
> |Network & msgpack|19.30|
> |Get table|14.29|
> |Get tuple & serialize|12.86|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
