[jira] [Updated] (IGNITE-20620) Add index availability command to catalog
[ https://issues.apache.org/jira/browse/IGNITE-20620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20620: - Reviewer: Roman Puchkovskiy > Add index availability command to catalog > - > > Key: IGNITE-20620 > URL: https://issues.apache.org/jira/browse/IGNITE-20620 > 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 > > We need to add a command to the directory that will change the index state > from write-only to read-write (availability). And also an event for changing > state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20602) Fix cache scan command page size to meet the limit argument
[
https://issues.apache.org/jira/browse/IGNITE-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774145#comment-17774145
]
Ignite TC Bot commented on IGNITE-20602:
{panel:title=Branch: [pull/10989/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10989/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility 1{color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=7372282]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheScanLimit[cmdHnd=cli] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheScanLimit[cmdHnd=jmx] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassWithSSLTest.testCacheScanLimit[cmdHnd=cli] -
PASSED{color}
{color:#8b}Control Utility (Zookeeper){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7372283]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheScanLimit[cmdHnd=cli] -
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerClusterByClassTest.testCacheScanLimit[cmdHnd=jmx] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7372347buildTypeId=IgniteTests24Java8_RunAll]
> Fix cache scan command page size to meet the limit argument
>
>
> Key: IGNITE-20602
> URL: https://issues.apache.org/jira/browse/IGNITE-20602
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cache scan command ignores the limit argument and preloads default page size
> entries count. This causes excessive heap usage and possible OOM if cache
> entries are large.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20626) Update ignite dependency: http-jetty
[ https://issues.apache.org/jira/browse/IGNITE-20626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-20626: - Labels: ise (was: ) > Update ignite dependency: http-jetty > > > Key: IGNITE-20626 > URL: https://issues.apache.org/jira/browse/IGNITE-20626 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Major > Labels: ise > Fix For: 2.16 > > > Update http-jetty to 9.4.53.v20231009 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
Mikhail Petrov created IGNITE-20627: --- Summary: Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command. Key: IGNITE-20627 URL: https://issues.apache.org/jira/browse/IGNITE-20627 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20626) Update ignite dependency: http-jetty
Alexey Gidaspov created IGNITE-20626: Summary: Update ignite dependency: http-jetty Key: IGNITE-20626 URL: https://issues.apache.org/jira/browse/IGNITE-20626 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Fix For: 2.16 Update http-jetty to 9.4.53.v20231009 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774115#comment-17774115
]
Vyacheslav Koptilin commented on IGNITE-20552:
--
Hello [~yafengshi] ,
I don't think that the root cause of the issue is the example itself. The
exception message says that `com.demo.TestController` cannot be serialized.
It means that the anonymous class that you mentioned captures the context and
this context includes the reference to your TestController class.
In general, you always should take into account this fact when you try to use
lambdas/anonymous classes with Apache Ignite.
Anyway, I will take a look at your patch. I agree that examples should work as
is, just copy-paste, and run.
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Assignee: yafengshi
>Priority: Major
> Labels: newbie
> Fix For: None
>
> Original Estimate: 1h
> Time Spent: 10m
> Remaining Estimate: 50m
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
>
[jira] [Updated] (IGNITE-20625) SELECT MIN(column), MAX(column) by ODBC throws exception
[
https://issues.apache.org/jira/browse/IGNITE-20625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-20625:
--
Summary: SELECT MIN(column), MAX(column) by ODBC throws exception (was:
SELECT MIN(column), MAX(column) by ODBC throws exceptions)
> SELECT MIN(column), MAX(column) by ODBC throws exception
>
>
> Key: IGNITE-20625
> URL: https://issues.apache.org/jira/browse/IGNITE-20625
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> h3. Steps to reproduce:
> # Connect to Ignite using ODBC driver (Python).
> # Execute separate queries one by one
> {code:java}
> DROP TABLE IF EXISTS PUBLIC.PARKING;
> CREATE TABLE PUBLIC.PARKING(ID INT, NAME VARCHAR(255), CAPACITY INT NOT NULL,
> b decimal,c date, CITY VARCHAR(20), PRIMARY KEY (ID, CITY));
> INSERT INTO PUBLIC.PARKING(ID, NAME, CAPACITY, CITY) VALUES(1, 'parking_1',
> 1, 'New York');
> SELECT MIN(CAPACITY), MAX(CAPACITY) FROM PUBLIC.PARKING; {code}
> h3. Expected result:
> Query executed successfully.
> h3. Actual result:
> The last query throws exception.
> {code:java}
> The value in stream is not a Binary data : 5{code}
> No errors in server log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20625) SELECT MIN(column), MAX(column) by ODBC throws exceptions
[
https://issues.apache.org/jira/browse/IGNITE-20625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-20625:
--
Description:
h3. Steps to reproduce:
# Connect to Ignite using ODBC driver (Python).
# Execute separate queries one by one
{code:java}
DROP TABLE IF EXISTS PUBLIC.PARKING;
CREATE TABLE PUBLIC.PARKING(ID INT, NAME VARCHAR(255), CAPACITY INT NOT NULL, b
decimal,c date, CITY VARCHAR(20), PRIMARY KEY (ID, CITY));
INSERT INTO PUBLIC.PARKING(ID, NAME, CAPACITY, CITY) VALUES(1, 'parking_1', 1,
'New York');
SELECT MIN(CAPACITY), MAX(CAPACITY) FROM PUBLIC.PARKING; {code}
h3. Expected result:
Query executed successfully.
h3. Actual result:
The last query throws exception.
{code:java}
The value in stream is not a Binary data : 5{code}
No errors in server log.
was:
h3. Steps to reproduce:
# Connect to Ignite using ODBC driver (Python).
# Execute `CREATE TABLE CAR(ID INT, PARKINGID INT NOT NULL, NAME VARCHAR(255),
CITY VARCHAR(20), PRIMARY KEY (ID, PARKINGID))`
h3. Expected result:
Query executed successfully.
h3. Actual result:
Exception is thrown.
{code:java}
CmdResult{exitCode=-1, result=, error=error executing CREATE TABLE CAR(ID INT,
PARKINGID INT NOT NULL, NAME VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY (ID,
PARKINGID)) got error ('HYC00', '[HYC00] Metadata for non-executed queries is
not supported (0) (SQLNumResultCols)'){code}
No errors in server log.
> SELECT MIN(column), MAX(column) by ODBC throws exceptions
> -
>
> Key: IGNITE-20625
> URL: https://issues.apache.org/jira/browse/IGNITE-20625
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> h3. Steps to reproduce:
> # Connect to Ignite using ODBC driver (Python).
> # Execute separate queries one by one
> {code:java}
> DROP TABLE IF EXISTS PUBLIC.PARKING;
> CREATE TABLE PUBLIC.PARKING(ID INT, NAME VARCHAR(255), CAPACITY INT NOT NULL,
> b decimal,c date, CITY VARCHAR(20), PRIMARY KEY (ID, CITY));
> INSERT INTO PUBLIC.PARKING(ID, NAME, CAPACITY, CITY) VALUES(1, 'parking_1',
> 1, 'New York');
> SELECT MIN(CAPACITY), MAX(CAPACITY) FROM PUBLIC.PARKING; {code}
> h3. Expected result:
> Query executed successfully.
> h3. Actual result:
> The last query throws exception.
> {code:java}
> The value in stream is not a Binary data : 5{code}
> No errors in server log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20625) SELECT MIN(column), MAX(column) by ODBC throws exceptions
Igor created IGNITE-20625:
-
Summary: SELECT MIN(column), MAX(column) by ODBC throws exceptions
Key: IGNITE-20625
URL: https://issues.apache.org/jira/browse/IGNITE-20625
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 3.0.0-beta2
Reporter: Igor
h3. Steps to reproduce:
# Connect to Ignite using ODBC driver (Python).
# Execute `CREATE TABLE CAR(ID INT, PARKINGID INT NOT NULL, NAME VARCHAR(255),
CITY VARCHAR(20), PRIMARY KEY (ID, PARKINGID))`
h3. Expected result:
Query executed successfully.
h3. Actual result:
Exception is thrown.
{code:java}
CmdResult{exitCode=-1, result=, error=error executing CREATE TABLE CAR(ID INT,
PARKINGID INT NOT NULL, NAME VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY (ID,
PARKINGID)) got error ('HYC00', '[HYC00] Metadata for non-executed queries is
not supported (0) (SQLNumResultCols)'){code}
No errors in server log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20615) SQL queries by ODBC throws exceptions
[
https://issues.apache.org/jira/browse/IGNITE-20615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor resolved IGNITE-20615.
---
Resolution: Not A Problem
Pyodbc tries to get metadata about non executed query - this feature is not yet
implemented
> SQL queries by ODBC throws exceptions
> -
>
> Key: IGNITE-20615
> URL: https://issues.apache.org/jira/browse/IGNITE-20615
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> h3. Steps to reproduce:
> # Connect to Ignite using ODBC driver (Python).
> # Execute `CREATE TABLE CAR(ID INT, PARKINGID INT NOT NULL, NAME
> VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY (ID, PARKINGID))`
> h3. Expected result:
> Query executed successfully.
> h3. Actual result:
> Exception is thrown.
> {code:java}
> CmdResult{exitCode=-1, result=, error=error executing CREATE TABLE CAR(ID
> INT, PARKINGID INT NOT NULL, NAME VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY
> (ID, PARKINGID)) got error ('HYC00', '[HYC00] Metadata for non-executed
> queries is not supported (0) (SQLNumResultCols)'){code}
> No errors in server log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20624) Race between getting logical topology and mapping fragments
Roman Puchkovskiy created IGNITE-20624:
--
Summary: Race between getting logical topology and mapping
fragments
Key: IGNITE-20624
URL: https://issues.apache.org/jira/browse/IGNITE-20624
Project: Ignite
Issue Type: Bug
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
MappingServiceImpl#nodesSetRef might contain an empty set when mapping if the
logical topology event hasn't occurred yet. This results in colocation targets
having {{nodes}} equal to 0, so no targets are colocated, even if they are
supposed to be. This results in 'ColocationMappingException: Targets are not
colocated' (thrown in AbstractTarget:123, as of commit
b9bd1c4db01a5377190b363c208375d845890265).
This is easily reproducible locally with
ItDataSchemaSyncTest#checkSchemasCorrectlyRestore()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20618) SQL: degradation of SELECT operations performance over time
[
https://issues.apache.org/jira/browse/IGNITE-20618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774091#comment-17774091
]
Andrey Mashenkov commented on IGNITE-20618:
---
[~Artukhov], do you have GC logs ?
> SQL: degradation of SELECT operations performance over time
> ---
>
> Key: IGNITE-20618
> URL: https://issues.apache.org/jira/browse/IGNITE-20618
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, sql-degr-insert.png,
> sql-degr-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
> {*}Steps{*}:
> * Start a 1 node cluster with the attached [^ignite-config.json]
> ** {*}raft.fsync = false{*}{*}{{*}}
> * Start the benchmark in pre-load mode – preload 100k entries:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> * Start the benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> The following *stable* throughput is observed in preload mode
> ({{{}INSERT{}}}):
> !sql-degr-insert.png!
> The following *unstable* throughput is observed on reads ({{{}SELECT):{}}}
> {{!sql-degr-select.png!}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20623) Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc)
[ https://issues.apache.org/jira/browse/IGNITE-20623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20623: -- Description: Currently, creating ds with Atomic atomicity, we also creating Transactional meta cache inside the same cache group when it's specified. This causes mixed atomicity inside the cache group. As a result, we unable to use proper counters (finally restrict mixed groups). was: Currently, creating ds with Atomic atomicity, we also creating Transactional meta cache inside the same cache group when it's specified. This causes mixed atomicity inside the cache group. As a result, we unable to use proper counters. > Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc) > > > Key: IGNITE-20623 > URL: https://issues.apache.org/jira/browse/IGNITE-20623 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Priority: Major > > Currently, creating ds with Atomic atomicity, we also creating Transactional > meta cache inside the same cache group when it's specified. > This causes mixed atomicity inside the cache group. > As a result, we unable to use proper counters (finally restrict mixed groups). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20623) Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc)
[ https://issues.apache.org/jira/browse/IGNITE-20623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-20623: -- Description: Currently, creating ds with Atomic atomicity, we also creating Transactional meta cache inside the same cache group when it's specified. This causes mixed atomicity inside the cache group. As a result, we unable to use proper counters. > Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc) > > > Key: IGNITE-20623 > URL: https://issues.apache.org/jira/browse/IGNITE-20623 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Priority: Major > > Currently, creating ds with Atomic atomicity, we also creating Transactional > meta cache inside the same cache group when it's specified. > This causes mixed atomicity inside the cache group. > As a result, we unable to use proper counters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20623) Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc)
Anton Vinogradov created IGNITE-20623: - Summary: Avoid mixed cache groups at datastructures (IgniteSet, IgniteQueue, etc) Key: IGNITE-20623 URL: https://issues.apache.org/jira/browse/IGNITE-20623 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19325) Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
[
https://issues.apache.org/jira/browse/IGNITE-19325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-19325:
---
Reviewer: Slava Koptilin
> Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
>
>
> Key: IGNITE-19325
> URL: https://issues.apache.org/jira/browse/IGNITE-19325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: iep-101, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> The general public of the issue has at least one test of checking the active
> actor for the placement driver. The test is already present in the code base
> (MultiActorPlacementDriverTest#prolongAfterActiveActorChanger), but it was
> muted a long time ago.
> *Implemetatiuon notes*
> The exception that currently appears in the test looks like the Metastorage
> one and does not depend on the placement driver:
> {noformat}
> [2023-10-11T14:55:14,672][INFO
> ][%mapdt_paaac_1234%MessagingService-inbound--0][MultiActorPlacementDriverTest]
> Meta storage is unavailable
> java.util.concurrent.CompletionException:
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: IGN-CMN-65535
> TraceId:54e6d210-5660-4f98-b175-b66ac45aeaf6 ETIMEDOUT:RPC exception:null
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.handleErrorResponse(RaftGroupServiceImpl.java:622)
> ~[main/:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$39(RaftGroupServiceImpl.java:536)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:416)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:368)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:350)
> ~[main/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException: ETIMEDOUT:RPC
> exception:null
> ... 12 more
> {noformat}
> The test should be unmuted and corrected for the current circumstances.
> *Difinition of done*
> We have a test (that runs in TC) that demonstrates the behavior of
> placement-driven behavior when the active actor is changing.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20622) OOMe during TPC-C scale10
Alexander Belyak created IGNITE-20622: - Summary: OOMe during TPC-C scale10 Key: IGNITE-20622 URL: https://issues.apache.org/jira/browse/IGNITE-20622 Project: Ignite Issue Type: Bug Components: networking Affects Versions: 3.0 Reporter: Alexander Belyak Got OOMe during loading TPC-C database with scale 10 (benchbase). TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20601) Support custom location for dumps
[ https://issues.apache.org/jira/browse/IGNITE-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20601: - Fix Version/s: 2.16 > Support custom location for dumps > - > > Key: IGNITE-20601 > URL: https://issues.apache.org/jira/browse/IGNITE-20601 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > User may want to create cache dump in any specific folder, like regular PDS > snapshots. > Ignite need to support this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19325) Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
[
https://issues.apache.org/jira/browse/IGNITE-19325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-19325:
--
Assignee: Vladislav Pyatkov
> Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
>
>
> Key: IGNITE-19325
> URL: https://issues.apache.org/jira/browse/IGNITE-19325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: iep-101, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> The general public of the issue has at least one test of checking the active
> actor for the placement driver. The test is already present in the code base
> (MultiActorPlacementDriverTest#prolongAfterActiveActorChanger), but it was
> muted a long time ago.
> *Implemetatiuon notes*
> The exception that currently appears in the test looks like the Metastorage
> one and does not depend on the placement driver:
> {noformat}
> [2023-10-11T14:55:14,672][INFO
> ][%mapdt_paaac_1234%MessagingService-inbound--0][MultiActorPlacementDriverTest]
> Meta storage is unavailable
> java.util.concurrent.CompletionException:
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: IGN-CMN-65535
> TraceId:54e6d210-5660-4f98-b175-b66ac45aeaf6 ETIMEDOUT:RPC exception:null
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.handleErrorResponse(RaftGroupServiceImpl.java:622)
> ~[main/:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$39(RaftGroupServiceImpl.java:536)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:416)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:368)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:350)
> ~[main/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException: ETIMEDOUT:RPC
> exception:null
> ... 12 more
> {noformat}
> The test should be unmuted and corrected for the current circumstances.
> *Difinition of done*
> We have a test (that runs in TC) that demonstrates the behavior of
> placement-driven behavior when the active actor is changing.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20484) NPE when some operation occurs when the primary replica is changing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774041#comment-17774041
]
Vladislav Pyatkov commented on IGNITE-20484:
Merged a39da06c100ded3feda6ece0a65361d0e8e5846a
> NPE when some operation occurs when the primary replica is changing
> ---
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Definition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
> *Implementation notes*
> Do not forget to check all places where the issue is mentioned (especially in
> TODO section).
> As discussed with [~sanpwc]:
> This exception is likely to be thrown when
> - we successfully get a primary replica on one node
> - send a message and the message is slightly slow to be delivered
> - we handle the received message on the recepient node and run
> {{placementDriver.getPrimaryReplica}}.
> If the previous lease has expired by the time we handle the message, the call
> to {{placementDriver}} will result in a {{null}} value instead of a
> {{ReplicaMeta}} instance. Hence the NPE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19325) Extend test covarage of placement driver manager: multinode placement driver cases
[
https://issues.apache.org/jira/browse/IGNITE-19325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-19325:
---
Description:
*Motivation*
The general public of the issue has at least one test of checking the active
actor for the placement driver. The test is already present in the code base
(MultiActorPlacementDriverTest#prolongAfterActiveActorChanger), but it was
muted a long time ago.
*Implemetatiuon notes*
The exception that currently appears in the test looks like the Metastorage one
and does not depend on the placement driver:
{noformat}
[2023-10-11T14:55:14,672][INFO
][%mapdt_paaac_1234%MessagingService-inbound--0][MultiActorPlacementDriverTest]
Meta storage is unavailable
java.util.concurrent.CompletionException:
org.apache.ignite.raft.jraft.rpc.impl.RaftException: IGN-CMN-65535
TraceId:54e6d210-5660-4f98-b175-b66ac45aeaf6 ETIMEDOUT:RPC exception:null
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
~[?:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.handleErrorResponse(RaftGroupServiceImpl.java:622)
~[main/:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$39(RaftGroupServiceImpl.java:536)
~[main/:?]
at
java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:416)
~[main/:?]
at
org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:368)
~[main/:?]
at
org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:350)
~[main/:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException: ETIMEDOUT:RPC
exception:null
... 12 more
{noformat}
The test should be unmuted and corrected for the current circumstances.
*Difinition of done*
We have a test (that runs in TC) that demonstrates the behavior of
placement-driven behavior when the active actor is changing.
was:
In the most part of tests placement, driver group contains only for one node.
In these circumstance, we forgot to cove cases when an active actor of the
manager is changed.
Need to implement tests based on multinode placement driver:
# Test where several active actors are working simultaneously
# Test were an active actor id changing from one node to another.
> Extend test covarage of placement driver manager: multinode placement driver
> cases
> --
>
> Key: IGNITE-19325
> URL: https://issues.apache.org/jira/browse/IGNITE-19325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: iep-101, ignite-3
>
> *Motivation*
> The general public of the issue has at least one test of checking the active
> actor for the placement driver. The test is already present in the code base
> (MultiActorPlacementDriverTest#prolongAfterActiveActorChanger), but it was
> muted a long time ago.
> *Implemetatiuon notes*
> The exception that currently appears in the test looks like the Metastorage
> one and does not depend on the placement driver:
> {noformat}
> [2023-10-11T14:55:14,672][INFO
> ][%mapdt_paaac_1234%MessagingService-inbound--0][MultiActorPlacementDriverTest]
> Meta storage is unavailable
> java.util.concurrent.CompletionException:
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: IGN-CMN-65535
> TraceId:54e6d210-5660-4f98-b175-b66ac45aeaf6 ETIMEDOUT:RPC exception:null
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
>
[jira] [Updated] (IGNITE-19325) Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
[
https://issues.apache.org/jira/browse/IGNITE-19325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-19325:
---
Summary: Unmute test
MultiActorPlacementDriverTest#prolongAfterActiveActorChanger (was: Extend test
covarage of placement driver manager: multinode placement driver cases)
> Unmute test MultiActorPlacementDriverTest#prolongAfterActiveActorChanger
>
>
> Key: IGNITE-19325
> URL: https://issues.apache.org/jira/browse/IGNITE-19325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: iep-101, ignite-3
>
> *Motivation*
> The general public of the issue has at least one test of checking the active
> actor for the placement driver. The test is already present in the code base
> (MultiActorPlacementDriverTest#prolongAfterActiveActorChanger), but it was
> muted a long time ago.
> *Implemetatiuon notes*
> The exception that currently appears in the test looks like the Metastorage
> one and does not depend on the placement driver:
> {noformat}
> [2023-10-11T14:55:14,672][INFO
> ][%mapdt_paaac_1234%MessagingService-inbound--0][MultiActorPlacementDriverTest]
> Meta storage is unavailable
> java.util.concurrent.CompletionException:
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: IGN-CMN-65535
> TraceId:54e6d210-5660-4f98-b175-b66ac45aeaf6 ETIMEDOUT:RPC exception:null
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.handleErrorResponse(RaftGroupServiceImpl.java:622)
> ~[main/:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$39(RaftGroupServiceImpl.java:536)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:416)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:368)
> ~[main/:?]
> at
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:350)
> ~[main/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException: ETIMEDOUT:RPC
> exception:null
> ... 12 more
> {noformat}
> The test should be unmuted and corrected for the current circumstances.
> *Difinition of done*
> We have a test (that runs in TC) that demonstrates the behavior of
> placement-driven behavior when the active actor is changing.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20484) NPE when some operation occurs when the primary replica is changing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20484:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> NPE when some operation occurs when the primary replica is changing
> ---
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Definition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
> *Implementation notes*
> Do not forget to check all places where the issue is mentioned (especially in
> TODO section).
> As discussed with [~sanpwc]:
> This exception is likely to be thrown when
> - we successfully get a primary replica on one node
> - send a message and the message is slightly slow to be delivered
> - we handle the received message on the recepient node and run
> {{placementDriver.getPrimaryReplica}}.
> If the previous lease has expired by the time we handle the message, the call
> to {{placementDriver}} will result in a {{null}} value instead of a
> {{ReplicaMeta}} instance. Hence the NPE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20484) NPE when some operation occurs when the primary replica is changing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20484:
---
Reviewer: Vladislav Pyatkov
> NPE when some operation occurs when the primary replica is changing
> ---
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Definition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
> *Implementation notes*
> Do not forget to check all places where the issue is mentioned (especially in
> TODO section).
> As discussed with [~sanpwc]:
> This exception is likely to be thrown when
> - we successfully get a primary replica on one node
> - send a message and the message is slightly slow to be delivered
> - we handle the received message on the recepient node and run
> {{placementDriver.getPrimaryReplica}}.
> If the previous lease has expired by the time we handle the message, the call
> to {{placementDriver}} will result in a {{null}} value instead of a
> {{ReplicaMeta}} instance. Hence the NPE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20484) NPE when some operation occurs when the primary replica is changing
[
https://issues.apache.org/jira/browse/IGNITE-20484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774014#comment-17774014
]
Vladislav Pyatkov commented on IGNITE-20484:
LGTM
> NPE when some operation occurs when the primary replica is changing
> ---
>
> Key: IGNITE-20484
> URL: https://issues.apache.org/jira/browse/IGNITE-20484
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> It happens that when the request is created, the primary replica is in this
> node, but when the request is executed in the replica, it has already lost
> its role.
> {noformat}
> [2023-09-25T11:03:24,408][WARN
> ][%iprct_tpclh_2%metastorage-watch-executor-2][ReplicaManager] Failed to
> process replica request [request=ReadWriteSingleRowReplicaRequestImpl
> [binaryRowMessage=BinaryRowMessageImpl
> [binaryTuple=java.nio.HeapByteBuffer[pos=0 lim=9 cap=9], schemaVersion=1],
> commitPartitionId=TablePartitionIdMessageImpl [partitionId=0, tableId=4],
> full=true, groupId=4_part_0, requestType=RW_UPSERT, term=24742070009862,
> timestampLong=24742430588928,
> transactionId=018acb5d-4e54-0006--705db0b1]]
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> ~[?:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:269)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$ensureReplicaIsPrimary$161(PartitionReplicaListener.java:2415)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 15 more
> {noformat}
> *Definition of done*
> In this case, we should throw the correct exception because the request
> cannot be handled in this replica anymore, and the matched transaction will
> be rolled back.
> *Implementation notes*
> Do not forget to check all places where the issue is mentioned (especially in
> TODO section).
> As discussed with [~sanpwc]:
> This exception is likely to be thrown when
> - we successfully get a primary replica on one node
> - send a message and the message is slightly slow to be delivered
> - we handle the received message on the recepient node and run
> {{placementDriver.getPrimaryReplica}}.
> If the previous lease has expired by the time we handle the message, the call
> to {{placementDriver}} will result in a {{null}} value instead of a
> {{ReplicaMeta}} instance. Hence the NPE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20597) Support cache group filter for dump
[ https://issues.apache.org/jira/browse/IGNITE-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20597: - Fix Version/s: 2.16 > Support cache group filter for dump > --- > > Key: IGNITE-20597 > URL: https://issues.apache.org/jira/browse/IGNITE-20597 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 40m > Remaining Estimate: 0h > > User may want to create cache dump only for specific set of cache groups. > Ignite need to support this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20621) Add a replication group index build completion listener to IndexBuilder
Kirill Tkalenko created IGNITE-20621: Summary: Add a replication group index build completion listener to IndexBuilder Key: IGNITE-20621 URL: https://issues.apache.org/jira/browse/IGNITE-20621 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 We need to add a replication group index build finish listener from *org.apache.ignite.internal.table.distributed.index.IndexBuilder* so that we can switch the index state from write-only to read-write. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20620) Add index availability command to catalog
Kirill Tkalenko created IGNITE-20620: Summary: Add index availability command to catalog Key: IGNITE-20620 URL: https://issues.apache.org/jira/browse/IGNITE-20620 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 We need to add a command to the directory that will change the index state from write-only to read-write (availability). And also an event for changing state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20385) Incorrect code INTERNAL_ERROR on node left
[
https://issues.apache.org/jira/browse/IGNITE-20385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773992#comment-17773992
]
Yury Gerzhedovich commented on IGNITE-20385:
[~xtern]LGTM
> Incorrect code INTERNAL_ERROR on node left
> ---
>
> Key: IGNITE-20385
> URL: https://issues.apache.org/jira/browse/IGNITE-20385
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> During execute SQL query we could got Exception with INTERNAL_ERR in case
> remote node left. Node left sholdn't be interpret as INTERNAL ERROR, due to
> it's normal situation and user can be informed about it.
> Let's map the situation to SqlException with code NODE_LEFT_ERR.
> Also need to check wich similar situation we could cover here.
> As start point need to find all places where used
> ExceptionUtils.withCauseAndCode method
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment
> [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
> at
> org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:106)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:100)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:76)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$15(ExecutionServiceImpl.java:747)
> 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.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:726)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> ...
> Caused by: org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535
> TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment
> [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
> at
> org.apache.ignite.internal.util.ExceptionUtils.lambda$withCauseAndCode$3(ExceptionUtils.java:440)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:467)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCauseAndCode(ExceptionUtils.java:440)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$12(ExecutionServiceImpl.java:714)
> 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.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:698)
> ... 7 more
> Caused by: org.apache.ignite.internal.sql.engine.NodeLeftException: IGN-CMN-5
> TraceId:bf122f9c-e697-4dfa-b59f-0692595fa94c Node left the cluster. Node:
> idt_n_1
> at
>
[jira] [Created] (IGNITE-20619) Sort out constants in CatalogUtils
Konstantin Orlov created IGNITE-20619: - Summary: Sort out constants in CatalogUtils Key: IGNITE-20619 URL: https://issues.apache.org/jira/browse/IGNITE-20619 Project: Ignite Issue Type: Improvement Reporter: Konstantin Orlov Currently, CatalogUtils has number of constant that actually don't belong to catalog. Some of them are enforced by SQL standard (see DEFAULT_LENGTH, MAX_DECIMAL_SCALE), some of them are enforced by limitations of others components (see MAX_PARTITION_COUNT, MAX_TIME_PRECISION). Let's revise all constants and move them do domains they belongs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20470) Ducktape to check dump performance
[ https://issues.apache.org/jira/browse/IGNITE-20470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20470: - Description: Dump creation can affect transactions performance with change listener and disc operations. We must create ducktape test to check this. Example test scenario: * Start nodes * Start transaction operations: insert, update, remove. * Create dump * Check dump consistency. Measure * Transaction performance penalty. * GC utilization. * Disc utilization. Params: * All types of caches(ATOMIC, TRANSACTIONAL) must be tested. * In-memory caches are primary use-case, but persistence has to be tested, also. was: Dump creation can affect transactions performance with change listener and disc operations. We must create ducktape test to check this. Example test scenario: * Start nodes * Start transaction operations: insert, update, remove. * Create dump * Check dump consistency. Measure * Transaction performance penalty. * GC utilization. * Disc utilization. > Ducktape to check dump performance > -- > > Key: IGNITE-20470 > URL: https://issues.apache.org/jira/browse/IGNITE-20470 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Sergey Korotkov >Priority: Major > Labels: IEP-109, ise > Time Spent: 0.5h > Remaining Estimate: 0h > > Dump creation can affect transactions performance with change listener and > disc operations. We must create ducktape test to check this. > Example test scenario: > * Start nodes > * Start transaction operations: insert, update, remove. > * Create dump > * Check dump consistency. > Measure > * Transaction performance penalty. > * GC utilization. > * Disc utilization. > Params: > * All types of caches(ATOMIC, TRANSACTIONAL) must be tested. > * In-memory caches are primary use-case, but persistence has to be tested, > also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20445) Clean up write intents for RW transaction on replication group nodes
[ https://issues.apache.org/jira/browse/IGNITE-20445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773954#comment-17773954 ] Vladislav Pyatkov commented on IGNITE-20445: Merged 228b5be6e3176ce40982b41f0dd3cf5c96452b09 > Clean up write intents for RW transaction on replication group nodes > > > Key: IGNITE-20445 > URL: https://issues.apache.org/jira/browse/IGNITE-20445 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 1.5h > Remaining Estimate: 0h > > If a transaction was committed/aborted and for any reason the cleanup > operation was not performed on a node, the write intent entries would still > be present in the storage. > When an RO transaction sees write intents, no matter on primary or on any > other node, it performs write intent resolution and returns the correct > result. > When an RW transaction sees write intents, we can get an exception. > _Imagine the case where a finished transaction left its write intents in the > storage of all nodes A, B and C. A is primary._ > _An RO transaction is executed on the primary A, it kicks off an async > cleanup (IGNITE-20041)._ > _The cleanup is a local task (not distributed to the replication group), thus > only the A's storage is cleaned. B and C storages still contain the same > write intent._ > _Now an RW transaction starts. It sees no write intents on A, executes its > action and the action is replicated to B and C. Execution of this task on B > and C will result in a storage exception since it's not allowed to have more > than one write intent per row._ > *Definition of Done* > The nodes of the replication group should perform cleanup of their storages > when they receive an UpdateCommand, before adding new write intents. > *Implementation details* > We can extend the update command with the timestamp of the latest commit on > primary. > If the nodes of the replication group see a write intent in their storage, > they will: > * +commit+ the write intent if the UpdateCommand`s latestCommitTimestamp is > greater than the commit timestamp of latest committed entry. > * +abort+ the write intent if he UpdateCommand`s latestCommitTimestamp is > equal to the commit timestamp of latest committed entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20445) Clean up write intents for RW transaction on replication group nodes
[ https://issues.apache.org/jira/browse/IGNITE-20445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773953#comment-17773953 ] Vladislav Pyatkov commented on IGNITE-20445: LGTM > Clean up write intents for RW transaction on replication group nodes > > > Key: IGNITE-20445 > URL: https://issues.apache.org/jira/browse/IGNITE-20445 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a transaction was committed/aborted and for any reason the cleanup > operation was not performed on a node, the write intent entries would still > be present in the storage. > When an RO transaction sees write intents, no matter on primary or on any > other node, it performs write intent resolution and returns the correct > result. > When an RW transaction sees write intents, we can get an exception. > _Imagine the case where a finished transaction left its write intents in the > storage of all nodes A, B and C. A is primary._ > _An RO transaction is executed on the primary A, it kicks off an async > cleanup (IGNITE-20041)._ > _The cleanup is a local task (not distributed to the replication group), thus > only the A's storage is cleaned. B and C storages still contain the same > write intent._ > _Now an RW transaction starts. It sees no write intents on A, executes its > action and the action is replicated to B and C. Execution of this task on B > and C will result in a storage exception since it's not allowed to have more > than one write intent per row._ > *Definition of Done* > The nodes of the replication group should perform cleanup of their storages > when they receive an UpdateCommand, before adding new write intents. > *Implementation details* > We can extend the update command with the timestamp of the latest commit on > primary. > If the nodes of the replication group see a write intent in their storage, > they will: > * +commit+ the write intent if the UpdateCommand`s latestCommitTimestamp is > greater than the commit timestamp of latest committed entry. > * +abort+ the write intent if he UpdateCommand`s latestCommitTimestamp is > equal to the commit timestamp of latest committed entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20444) Sql. Add restrictions for execution tx related statements with single statement mode.
[
https://issues.apache.org/jira/browse/IGNITE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20444:
-
Assignee: Maksim Zhuravkov
> Sql. Add restrictions for execution tx related statements with single
> statement mode.
> -
>
> Key: IGNITE-20444
> URL: https://issues.apache.org/jira/browse/IGNITE-20444
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Append single statement restrictions for using with new tx related sql syntax
> [1] implementation.
> {code:java}
> try (Session ses = client.sql().createSession()) {
> ses.execute(
> null, "_new transactional statement from
> ignite-20442_" <-- such calls need to be rejected
> ).close();
> ses.execute(
> null,
> "some other sql statement"
> ).close();
> }
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-20442
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20618) SQL: degradation of SELECT operations performance over time
[
https://issues.apache.org/jira/browse/IGNITE-20618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20618:
Ignite Flags: (was: Docs Required,Release Notes Required)
> SQL: degradation of SELECT operations performance over time
> ---
>
> Key: IGNITE-20618
> URL: https://issues.apache.org/jira/browse/IGNITE-20618
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, sql-degr-insert.png,
> sql-degr-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
> {*}Steps{*}:
> * Start a 1 node cluster with the attached [^ignite-config.json]
> ** {*}raft.fsync = false{*}{*}{{*}}
> * Start the benchmark in pre-load mode – preload 100k entries:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> * Start the benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> The following *stable* throughput is observed in preload mode
> ({{{}INSERT{}}}):
> !sql-degr-insert.png!
> The following *unstable* throughput is observed on reads ({{{}SELECT):{}}}
> {{!sql-degr-select.png!}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20618) SQL: degradation of SELECT operations performance over time
[
https://issues.apache.org/jira/browse/IGNITE-20618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20618:
Labels: ignite-3 performance (was: )
> SQL: degradation of SELECT operations performance over time
> ---
>
> Key: IGNITE-20618
> URL: https://issues.apache.org/jira/browse/IGNITE-20618
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, sql-degr-insert.png,
> sql-degr-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
> {*}Steps{*}:
> * Start a 1 node cluster with the attached [^ignite-config.json]
> ** {*}raft.fsync = false{*}{*}{{*}}
> * Start the benchmark in pre-load mode – preload 100k entries:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> * Start the benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
> The following *stable* throughput is observed in preload mode
> ({{{}INSERT{}}}):
> !sql-degr-insert.png!
> The following *unstable* throughput is observed on reads ({{{}SELECT):{}}}
> {{!sql-degr-select.png!}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
[
https://issues.apache.org/jira/browse/IGNITE-20617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20617:
Ignite Flags: (was: Docs Required,Release Notes Required)
> SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
>
>
> Key: IGNITE-20617
> URL: https://issues.apache.org/jira/browse/IGNITE-20617
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, jdbc-1node-select.png,
> jdbc-2nodes-select.png, sql-1node-select.png, sql-2nodes-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
>
> Steps:
> * Run an Ignite cluster of 2 nodes with the attached config
> [^ignite-config.json] .
> ** *fsync = false*
> * Run the SQL YCSB benchmark in preload mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.60}}
> * Run the SQL YCSB benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> operationcount=1 -p recordcount=1 -p dataintegrity=true -p
> measurementtype=timeseries -p hosts=192.168.1.60 -s}}
> * Observe the following average throughput on reads:
> !sql-2nodes-select.png!
> Repeat the test with only 1 server node and observe {*}~20x better throughput
> on reads{*}:
> !sql-1node-select.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20618) SQL: degradation of SELECT operations performance over time
Ivan Artiukhov created IGNITE-20618:
---
Summary: SQL: degradation of SELECT operations performance over
time
Key: IGNITE-20618
URL: https://issues.apache.org/jira/browse/IGNITE-20618
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Ivan Artiukhov
Attachments: ignite-config.json, sql-degr-insert.png,
sql-degr-select.png
Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
Benchmark:
[https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
{{{}preparedStatement{}}}.
{*}Steps{*}:
* Start a 1 node cluster with the attached [^ignite-config.json]
** {*}raft.fsync = false{*}{*}{{*}}
* Start the benchmark in pre-load mode – preload 100k entries:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
* Start the benchmark in 100% read mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
hosts=192.168.1.43 -p recordcount=10 -p operationcount=10}}
The following *stable* throughput is observed in preload mode ({{{}INSERT{}}}):
!sql-degr-insert.png!
The following *unstable* throughput is observed on reads ({{{}SELECT):{}}}
{{!sql-degr-select.png!}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
[
https://issues.apache.org/jira/browse/IGNITE-20617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20617:
Description:
Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
Benchmark:
[https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
{{{}preparedStatement{}}}.
Steps:
* Run an Ignite cluster of 2 nodes with the attached config
[^ignite-config.json] .
** *fsync = false*
* Run the SQL YCSB benchmark in preload mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
hosts=192.168.1.60}}
* Run the SQL YCSB benchmark in 100% read mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
operationcount=1 -p recordcount=1 -p dataintegrity=true -p
measurementtype=timeseries -p hosts=192.168.1.60 -s}}
* Observe the following average throughput on reads:
!sql-2nodes-select.png!
Repeat the test with only 1 server node and observe {*}~20x better throughput
on reads{*}:
!sql-1node-select.png!
was:
Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
Benchmark:
[https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
{{{}preparedStatement{}}}.
Steps:
* Run an Ignite cluster of 2 nodes with the attached config
[^ignite-config.json]
* Run the SQL YCSB benchmark in preload mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
hosts=192.168.1.60}}
* Run the SQL YCSB benchmark in 100% read mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
operationcount=1 -p recordcount=1 -p dataintegrity=true -p
measurementtype=timeseries -p hosts=192.168.1.60 -s}}
* Observe the following average throughput on reads:
!sql-2nodes-select.png!
Repeat the test with only 1 server node and observe {*}~20x better throughput
on reads{*}:
!sql-1node-select.png!
> SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
>
>
> Key: IGNITE-20617
> URL: https://issues.apache.org/jira/browse/IGNITE-20617
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, jdbc-1node-select.png,
> jdbc-2nodes-select.png, sql-1node-select.png, sql-2nodes-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
>
> Steps:
> * Run an Ignite cluster of 2 nodes with the attached config
> [^ignite-config.json] .
> ** *fsync = false*
> * Run the SQL YCSB benchmark in preload mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.60}}
> * Run the SQL YCSB benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> operationcount=1 -p recordcount=1 -p dataintegrity=true -p
> measurementtype=timeseries -p hosts=192.168.1.60 -s}}
> * Observe the following average throughput on reads:
> !sql-2nodes-select.png!
> Repeat the test with only 1 server node and observe {*}~20x better throughput
> on reads{*}:
> !sql-1node-select.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20615) SQL queries by ODBC throws exceptions
[
https://issues.apache.org/jira/browse/IGNITE-20615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-20615:
--
Labels: ignite-3 (was: )
> SQL queries by ODBC throws exceptions
> -
>
> Key: IGNITE-20615
> URL: https://issues.apache.org/jira/browse/IGNITE-20615
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> h3. Steps to reproduce:
> # Connect to Ignite using ODBC driver (Python).
> # Execute `CREATE TABLE CAR(ID INT, PARKINGID INT NOT NULL, NAME
> VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY (ID, PARKINGID))`
> h3. Expected result:
> Query executed successfully.
> h3. Actual result:
> Exception is thrown.
> {code:java}
> CmdResult{exitCode=-1, result=, error=error executing CREATE TABLE CAR(ID
> INT, PARKINGID INT NOT NULL, NAME VARCHAR(255), CITY VARCHAR(20), PRIMARY KEY
> (ID, PARKINGID)) got error ('HYC00', '[HYC00] Metadata for non-executed
> queries is not supported (0) (SQLNumResultCols)'){code}
> No errors in server log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
[
https://issues.apache.org/jira/browse/IGNITE-20617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773929#comment-17773929
]
Ivan Artiukhov commented on IGNITE-20617:
-
The similar drop is observed on the following JDBC benchmark:
[https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteJdbcClient.java]
100% read on 2 nodes cluster:
!jdbc-2nodes-select.png!
100% read on 1 node cluster:
!jdbc-1node-select.png!
> SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
>
>
> Key: IGNITE-20617
> URL: https://issues.apache.org/jira/browse/IGNITE-20617
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, jdbc-1node-select.png,
> jdbc-2nodes-select.png, sql-1node-select.png, sql-2nodes-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
>
> Steps:
> * Run an Ignite cluster of 2 nodes with the attached config
> [^ignite-config.json]
> * Run the SQL YCSB benchmark in preload mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.60}}
> * Run the SQL YCSB benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> operationcount=1 -p recordcount=1 -p dataintegrity=true -p
> measurementtype=timeseries -p hosts=192.168.1.60 -s}}
> * Observe the following average throughput on reads:
> !sql-2nodes-select.png!
> Repeat the test with only 1 server node and observe {*}~20x better throughput
> on reads{*}:
> !sql-1node-select.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
[
https://issues.apache.org/jira/browse/IGNITE-20617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20617:
Attachment: jdbc-1node-select.png
> SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
>
>
> Key: IGNITE-20617
> URL: https://issues.apache.org/jira/browse/IGNITE-20617
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, jdbc-1node-select.png,
> jdbc-2nodes-select.png, sql-1node-select.png, sql-2nodes-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
>
> Steps:
> * Run an Ignite cluster of 2 nodes with the attached config
> [^ignite-config.json]
> * Run the SQL YCSB benchmark in preload mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.60}}
> * Run the SQL YCSB benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> operationcount=1 -p recordcount=1 -p dataintegrity=true -p
> measurementtype=timeseries -p hosts=192.168.1.60 -s}}
> * Observe the following average throughput on reads:
> !sql-2nodes-select.png!
> Repeat the test with only 1 server node and observe {*}~20x better throughput
> on reads{*}:
> !sql-1node-select.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
[
https://issues.apache.org/jira/browse/IGNITE-20617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artiukhov updated IGNITE-20617:
Attachment: jdbc-2nodes-select.png
> SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
>
>
> Key: IGNITE-20617
> URL: https://issues.apache.org/jira/browse/IGNITE-20617
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ignite-config.json, jdbc-2nodes-select.png,
> sql-1node-select.png, sql-2nodes-select.png
>
>
> Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
> {{{}preparedStatement{}}}.
>
> Steps:
> * Run an Ignite cluster of 2 nodes with the attached config
> [^ignite-config.json]
> * Run the SQL YCSB benchmark in preload mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
> hosts=192.168.1.60}}
> * Run the SQL YCSB benchmark in 100% read mode:
> ** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
> /opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
> operationcount=1 -p recordcount=1 -p dataintegrity=true -p
> measurementtype=timeseries -p hosts=192.168.1.60 -s}}
> * Observe the following average throughput on reads:
> !sql-2nodes-select.png!
> Repeat the test with only 1 server node and observe {*}~20x better throughput
> on reads{*}:
> !sql-1node-select.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20617) SQL: ~20x performance degradation in SELECTS (2 nodes VS 1 node)
Ivan Artiukhov created IGNITE-20617:
---
Summary: SQL: ~20x performance degradation in SELECTS (2 nodes VS
1 node)
Key: IGNITE-20617
URL: https://issues.apache.org/jira/browse/IGNITE-20617
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Ivan Artiukhov
Attachments: ignite-config.json, sql-1node-select.png,
sql-2nodes-select.png
Ignite 3, rev. 7d188ac7ae068bd69ff0e6e6cfe5a32ac5749d17
Benchmark:
[https://github.com/gridgain/YCSB/blob/ycsb-2023.3/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
The benchmark establishes an SQL {{Session}} and perform {{SELECTs}} via
{{{}preparedStatement{}}}.
Steps:
* Run an Ignite cluster of 2 nodes with the attached config
[^ignite-config.json]
* Run the SQL YCSB benchmark in preload mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -load -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
recordcount=1 -p dataintegrity=true -p measurementtype=timeseries -p
hosts=192.168.1.60}}
* Run the SQL YCSB benchmark in 100% read mode:
** {{-db site.ycsb.db.ignite3.IgniteSqlClient -t -P
/opt/pubagent/poc/config/ycsb/workloads/workloadc -threads 1 -p
operationcount=1 -p recordcount=1 -p dataintegrity=true -p
measurementtype=timeseries -p hosts=192.168.1.60 -s}}
* Observe the following average throughput on reads:
!sql-2nodes-select.png!
Repeat the test with only 1 server node and observe {*}~20x better throughput
on reads{*}:
!sql-1node-select.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20457) Verify commitTimestamp against enlisted partitions expiration timestamps
[ https://issues.apache.org/jira/browse/IGNITE-20457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20457: - Reviewer: Vladislav Pyatkov > Verify commitTimestamp against enlisted partitions expiration timestamps > > > Key: IGNITE-20457 > URL: https://issues.apache.org/jira/browse/IGNITE-20457 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Blocker > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > On tx commit It’s required to check that commit timestamp is less than > expiration timestamps for all enlisted partitions > h3. Implementation Notes > * Added TxManagerImpl#verifyCommitTimestamp method that checks whether > previously enlisted primary replicas aren't expired and that commit timestamp > is less or equal than primary replicas expiration timestamp. Given method > will either complete result future with void or PrimaryReplicaExpiredException > * Added aforementioned verifyCommitTimestamp into TxManagerImpl#finish flow > * Added PlacementDriver as an additional TxManagerImpl constructor param in > order to retrieve current primary replicas for the futher checks in > verifyCommitTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20616: - Epic Link: IGNITE-17766 > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20616: - Issue Type: Improvement (was: Bug) > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20616: - Ignite Flags: (was: Docs Required,Release Notes Required) > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20616: - Fix Version/s: 3.0.0-beta2 > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Fix For: 3.0.0-beta2 > > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20616: - Labels: ignite-3 (was: ) > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-20616: Assignee: Kirill Tkalenko > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 3.0.0-beta2 > > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20616: - Description: h3. Motivation ensureReplicaIsPrimary by design should check whether replica is primary instead of await one, thus corresponding awaitPrimaryReplica call within BuildIndexReplicaRequest processing should be substituted with getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may return null if there's no primary replica for the requested point in time. > ensureReplicaIsPrimary should use getPrimaryReplica instead of > awaitPrimaryReplica > -- > > Key: IGNITE-20616 > URL: https://issues.apache.org/jira/browse/IGNITE-20616 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > ensureReplicaIsPrimary by design should check whether replica is primary > instead of await one, thus corresponding awaitPrimaryReplica call within > BuildIndexReplicaRequest processing should be substituted with > getPrimaryReplica counterpart. Please be aware that getPrimaryReplica may > return null if there's no primary replica for the requested point in time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20616) ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica
Alexander Lapin created IGNITE-20616: Summary: ensureReplicaIsPrimary should use getPrimaryReplica instead of awaitPrimaryReplica Key: IGNITE-20616 URL: https://issues.apache.org/jira/browse/IGNITE-20616 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
