[jira] [Created] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
Dmitrii Kriukov created IGNITE-21185:
Summary: In DistributionFunction strings are compared with ==
instead of equals()
Key: IGNITE-21185
URL: https://issues.apache.org/jira/browse/IGNITE-21185
Project: Ignite
Issue Type: Bug
Reporter: Dmitrii Kriukov
Line 157:
{color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21184) Comparator SER_VER_COMPARATOR in GridCacheMvcc doesn't return 0 for equal objects
[
https://issues.apache.org/jira/browse/IGNITE-21184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801219#comment-17801219
]
Dmitrii Kriukov commented on IGNITE-21184:
--
If it'a intentional ( i can see an assert in the line 258 -
{color:#cc7832}assert {color}cmp !=
{color:#6897bb}0{color}{color:#cc7832};{color}
), maybe it makes sense to reflect that in a comment.
But I'd rather remove the assert and have a proper comparator.
> Comparator SER_VER_COMPARATOR in GridCacheMvcc doesn't return 0 for equal
> objects
> -
>
> Key: IGNITE-21184
> URL: https://issues.apache.org/jira/browse/IGNITE-21184
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Major
>
> I'm going to provide a PR
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21184) Comparator SER_VER_COMPARATOR in GridCacheMvcc doesn't return 0 for equal objects
Dmitrii Kriukov created IGNITE-21184: Summary: Comparator SER_VER_COMPARATOR in GridCacheMvcc doesn't return 0 for equal objects Key: IGNITE-21184 URL: https://issues.apache.org/jira/browse/IGNITE-21184 Project: Ignite Issue Type: Bug Reporter: Dmitrii Kriukov I'm going to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20323) SQL hint for join type.
[
https://issues.apache.org/jira/browse/IGNITE-20323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801201#comment-17801201
]
Ignite TC Bot commented on IGNITE-20323:
{panel:title=Branch: [pull/10918/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=7682224]]
{panel}
{panel:title=Branch: [pull/10918/head] Base: [master] : New Tests
(13)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
13|https://ci2.ignite.apache.org/viewLog.html?buildId=7682181]]
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testDisableMergeJoin - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testDisableMergeJoinWith3Tables - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testDisableCNLJoin - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testSeveralDisables - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testMergeJoinEnabled - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testDisableNLJoin - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testDisableJoinTypeInSubquery - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testHintsErrors - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testNestedHintOverrides - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testNLJoinEnabled - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
JoinTypeHintPlannerTest.testCNLJoinEnabled - PASSED{color}
... and 2 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7682258&buildTypeId=IgniteTests24Java8_RunAll]
> SQL hint for join type.
> ---
>
> Key: IGNITE-20323
> URL: https://issues.apache.org/jira/browse/IGNITE-20323
> Project: Ignite
> Issue Type: Task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Additionally to the hint for locked join order, we might have a hint for
> choosing join type. Like 'USE_NL' or 'USE_MERGE' OracleDB hint. To implement,
> we might base all join rules on the same abstract join rule aware of known
> join types and join type hints. There, we could process join type hints
> enabling or disabling current join type converter rule.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21171) Calcite engine. Field nullability flag lost for data types with precession or scale
[
https://issues.apache.org/jira/browse/IGNITE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801198#comment-17801198
]
Ignite TC Bot commented on IGNITE-21171:
{panel:title=Branch: [pull/11154/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11154/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7680081]]
* {color:#013220}IgniteCalciteTestSuite:
TableDdlIntegrationTest.createTableWithNullability - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7680158&buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Field nullability flag lost for data types with precession or
> scale
> ---
>
> Key: IGNITE-21171
> URL: https://issues.apache.org/jira/browse/IGNITE-21171
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> CREATE TABLE test(id INT PRIMARY KEY, val DECIMAL(10,2));
> INSERT INTO test(id, val) VALUES (0, NULL); {code}
> Fail with: {{Column 'VAL' has no default value and does not allow NULLs}}
> But it works if {{val}} data type is {{DECIMAL}} or {{INT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801194#comment-17801194 ] Vipul Thakur commented on IGNITE-21059: --- Hi [~zstan] Today we got another issue in production : 2023-12-29T03:13:47,467][INFO ][wal-file-cleaner%EVENT_PROCESSING-#715%EVENT_PROCESSING%][FileWriteAheadLogManager] *Starting to clean WAL archive [highIdx=8303528, currSize=512.0 MB, maxSize=1.0 GB]* 2023-12-29T03:13:47,468][INFO ][wal-file-cleaner%EVENT_PROCESSING-#715%EVENT_PROCESSING%][FileWriteAheadLogManager] Finish clean WAL archive [cleanCnt=1, currSize=448.0 MB, maxSize=1.0 GB] 2023-12-29T03:13:47,563][INFO ][wal-file-archiver%EVENT_PROCESSING-#714%EVENT_PROCESSING%][FileWriteAheadLogManager] Copied file [src=/datastore2/wal/node00-eb1d0680-c0b7-41dd-a0b1-f1f5e419cbe6/0005.wal, dst=/datastore2/archive/node00-eb1d0680-c0b7-41dd-a0b1-f1f5e419cbe6/08303535.wal] 2023-12-29T03:14:17,080][INFO ][wal-file-archiver%EVENT_PROCESSING-#714%EVENT_PROCESSING%][Fil In the above log it seems wal archive is also filling up fast. Should we also set maxWalArchiveSize to a higher value from the default 1GB. Find the logs from one of our node and this can bee seen in all the nodes [^nohup_12.out] Please help us with your observations. > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: Ignite_server_logs.zip, cache-config-1.xml, > client-service.zip, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup-1.out, ignite-server-nohup.out, image.png, long_txn_.png, > nohup_12.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 5 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB SDD. > PFB for the attached config.[I have added it as attachment for review] > I have also added the server logs from the same time when issue happened. > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21059) We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running cache operations
[ https://issues.apache.org/jira/browse/IGNITE-21059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vipul Thakur updated IGNITE-21059: -- Attachment: nohup_12.out > We have upgraded our ignite instance from 2.7.6 to 2.14. Found long running > cache operations > > > Key: IGNITE-21059 > URL: https://issues.apache.org/jira/browse/IGNITE-21059 > Project: Ignite > Issue Type: Bug > Components: binary, clients >Affects Versions: 2.14 >Reporter: Vipul Thakur >Priority: Critical > Attachments: Ignite_server_logs.zip, cache-config-1.xml, > client-service.zip, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt2, > digiapi-eventprocessing-app-zone1-696c8c4946-62jbx-jstck.txt3, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt1, > digiapi-eventprocessing-app-zone1-696c8c4946-7d57w-jstck.txt2, > ignite-server-nohup-1.out, ignite-server-nohup.out, image.png, long_txn_.png, > nohup_12.out > > > We have recently upgraded from 2.7.6 to 2.14 due to the issue observed in > production environment where cluster would go in hang state due to partition > map exchange. > Please find the below ticket which i created a while back for ignite 2.7.6 > https://issues.apache.org/jira/browse/IGNITE-13298 > So we migrated the apache ignite version to 2.14 and upgrade happened > smoothly but on the third day we could see cluster traffic dip again. > We have 5 nodes in a cluster where we provide 400 GB of RAM and more than 1 > TB SDD. > PFB for the attached config.[I have added it as attachment for review] > I have also added the server logs from the same time when issue happened. > We have set txn timeout as well as socket timeout both at server and client > end for our write operations but seems like sometimes cluster goes into hang > state and all our get calls are stuck and slowly everything starts to freeze > our jms listener threads and every thread reaches a choked up state in > sometime. > Due to which our read services which does not even use txn to retrieve data > also starts to choke. Ultimately leading to end user traffic dip. > We were hoping product upgrade will help but that has not been the case till > now. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Labels: ise (was: )
> .NET platform test timeouts
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> If I'm correct, this happens after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
> {code}
> of after
> {code:java}
> Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
> {code}
> The issue might be related to:
> {code:java}
> JAVA_HOME: /opt/java/jdk-ora-8
> {code}
> {code:java}
> if (TestUtilsJni.GetJavaMajorVersion() <= 11)
> {
> // Old Ignite versions can't start on new JDKs (support
> was not yet added).
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.4.0", 0 };
> yield return new object[] { JavaServer.GroupIdIgnite,
> "2.6.0", 1 };
> }
> {code}
> {code:java}
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
> {code}
> {code:java}
> PlatformProcessUtils >> [INFO] Compiling 1 source file to
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
>
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
> uses unchecked or unsafe operations.
> PlatformProcessUtils >> [WARNING]
> /data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
> Recompile with -Xlint:unchecked for details.
> PlatformProcessUtils >> [INFO]
> PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli)
> @ ignite-maven-server ---
> PlatformProcessUtils >> Can't load log handler
> "org.apache.ignite.logger.java.JavaLoggerFileHandler"
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> java.lang.ClassNotFoundException:
> org.apache.ignite.logger.java.JavaLoggerFileHandler
> PlatformProcessUtils >> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> PlatformProcessUtils >> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
> PlatformProcessUtils >> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> PlatformProcessUtils >> at
> java.util.logging.LogManager$5.run(LogManager.java:965)
> PlatformProcessUtils >> at
> java.security.AccessController.doPrivileged(Native Method)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
> PlatformProcessUtils >> at
> java.util.logging.LogManager.access$1500(LogManager.java:145)
> PlatformProcessUtils >> at
> java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667)
> PlatformProcessUtils >> at
> java.util.logging.Logger.getHandlers(Logger.java:1777)
> PlatformProcessUtils >> at
> org.apache.ignite
[jira] [Created] (IGNITE-21183) Thin client: Avoid blocking of client-connector threads by transactional operations
Aleksey Plekhanov created IGNITE-21183:
--
Summary: Thin client: Avoid blocking of client-connector threads
by transactional operations
Key: IGNITE-21183
URL: https://issues.apache.org/jira/browse/IGNITE-21183
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently client-connector threads (workers for thin-client operations) can be
blocked for a long time by cache operation within transaction. If there is not
enough threads configured it can lead to deadlocks. For example, if we have
{{n}} threads and {{n+1}} clients which start the pessimistic transaction and
try to modify the same key, first client lock the key, other {{n}} clients wait
on locked key and hold the whole thread put by blocking operations.
Commit/rollback from the first client can never be proceeded, since all threads
are occupied, and threads can't be released, since they are waiting for
commit/rollback from the first client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21182) Temporary increase lease interval to eliminate issues related to long watch events processing
Alexander Lapin created IGNITE-21182: Summary: Temporary increase lease interval to eliminate issues related to long watch events processing Key: IGNITE-21182 URL: https://issues.apache.org/jira/browse/IGNITE-21182 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
If I'm correct, this happens after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
{code}
of after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
{code}
The issue might be related to:
{code:java}
JAVA_HOME: /opt/java/jdk-ora-8
{code}
{code:java}
if (TestUtilsJni.GetJavaMajorVersion() <= 11)
{
// Old Ignite versions can't start on new JDKs (support was
not yet added).
yield return new object[] { JavaServer.GroupIdIgnite,
"2.4.0", 0 };
yield return new object[] { JavaServer.GroupIdIgnite,
"2.6.0", 1 };
}
{code}
{code:java}
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
{code}
{code:java}
PlatformProcessUtils >> [INFO] Compiling 1 source file to
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
uses unchecked or unsafe operations.
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
Recompile with -Xlint:unchecked for details.
PlatformProcessUtils >> [INFO]
PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli) @
ignite-maven-server ---
PlatformProcessUtils >> Can't load log handler
"org.apache.ignite.logger.java.JavaLoggerFileHandler"
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:418)
PlatformProcessUtils >> at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:351)
PlatformProcessUtils >> at
java.util.logging.LogManager$5.run(LogManager.java:965)
PlatformProcessUtils >> at
java.security.AccessController.doPrivileged(Native Method)
PlatformProcessUtils >> at
java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
PlatformProcessUtils >> at
java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
PlatformProcessUtils >> at
java.util.logging.LogManager.access$1500(LogManager.java:145)
PlatformProcessUtils >> at
java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667)
PlatformProcessUtils >> at
java.util.logging.Logger.getHandlers(Logger.java:1777)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.findHandler(JavaLogger.java:411)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.configure(JavaLogger.java:241)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.(JavaLogger.java:181)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.(JavaLogger.java:135)
PlatformProcessUtils >> at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.initLogger(IgnitionEx.java:2454)
PlatformProcessUtils >> at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.initializeConfiguration(IgnitionEx.java:2122)
[jira] [Updated] (IGNITE-21181) Failure to resolve a primary replica after stopping a node
[ https://issues.apache.org/jira/browse/IGNITE-21181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21181: - Epic Link: IGNITE-21174 > Failure to resolve a primary replica after stopping a node > -- > > Key: IGNITE-21181 > URL: https://issues.apache.org/jira/browse/IGNITE-21181 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The scenario is that the cluster consists of 3 nodes (0, 1, 2). Primary > replica of the sole partition is on node 0. Then node 0 is stopped and an > attempt to do a put via node 2 is done. The partition still has majority, but > the put results in the following: > > org.apache.ignite.tx.TransactionException: IGN-REP-5 > TraceId:55c59c96-17d1-4efc-8e3c-cca81b8b41ad Failed to resolve the primary > replica node [consistentId=itrst_ncisasiti_0] > > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$69(InternalTableImpl.java:1749) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946) > at > java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlist(InternalTableImpl.java:1739) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistWithRetry(InternalTableImpl.java:480) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistInTx(InternalTableImpl.java:301) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.upsert(InternalTableImpl.java:965) > at > org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$10(KeyValueViewImpl.java:196) > at > org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:111) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) > at > org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:111) > at > org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102) > at > org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:193) > at > org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:185) > at > org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:257) > at > org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:253) > at > org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(ItTableRaftSnapshotsTest.java:473) > > This can be reproduced using > ItTableRaftSnapshotsTest#nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21165) .NET platform test timeouts
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21165:
--
Description:
There are many timeouted test runs in the .NET suite. Example:
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
{code:java}
The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
{buildId=7678070} has been running for more than 40 minutes. Terminating...
{code}
Looks like only port 47500 is requested while server node started on another.
Probably a previous test didn't release the port yet.
{code:java}
Successfully bound communication NIO server to TCP port [port=47101,
locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
{code}
{code:java}
Failed to connect to any address from IP finder (make sure IP finder addresses
are correct and firewalls are disabled on all host machines): [/127.0.0.1:47500]
{code}
If I'm correct, this happens after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestPartitionAwarenessDisablesAutomaticallyOnVersionsOlderThan140
{code}
of after
{code:java}
Apache.Ignite.Core.Tests.Client.Compatibility.ClientServerCompatibilityTest("org.apache.ignite","2.8.0",6).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150
{code}
The issue might be related to:
{code:java}
JAVA_HOME: /opt/java/jdk-ora-8
{code}
{code:java}
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/ignite/ignite-core/2.4.0/ignite-core-2.4.0.jar
{code}
{code:java}
if (TestUtilsJni.GetJavaMajorVersion() <= 11)
{
// Old Ignite versions can't start on new JDKs (support was
not yet added).
yield return new object[] { JavaServer.GroupIdIgnite,
"2.4.0", 0 };
yield return new object[] { JavaServer.GroupIdIgnite,
"2.6.0", 1 };
}
{code}
{code:java}
PlatformProcessUtils >> [INFO] Compiling 1 source file to
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/target/classes
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java
uses unchecked or unsafe operations.
PlatformProcessUtils >> [WARNING]
/data/tcAgent/work/7bc1c54bc719b67c/modules/platforms/dotnet/Apache.Ignite.Core.Tests/JavaServer/src/main/java/Runner.java:
Recompile with -Xlint:unchecked for details.
PlatformProcessUtils >> [INFO]
PlatformProcessUtils >> [INFO] --- exec-maven-plugin:3.0.0:java (default-cli) @
ignite-maven-server ---
PlatformProcessUtils >> Can't load log handler
"org.apache.ignite.logger.java.JavaLoggerFileHandler"
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> java.lang.ClassNotFoundException:
org.apache.ignite.logger.java.JavaLoggerFileHandler
PlatformProcessUtils >> at
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:418)
PlatformProcessUtils >> at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
PlatformProcessUtils >> at
java.lang.ClassLoader.loadClass(ClassLoader.java:351)
PlatformProcessUtils >> at
java.util.logging.LogManager$5.run(LogManager.java:965)
PlatformProcessUtils >> at
java.security.AccessController.doPrivileged(Native Method)
PlatformProcessUtils >> at
java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
PlatformProcessUtils >> at
java.util.logging.LogManager.initializeGlobalHandlers(LogManager.java:1578)
PlatformProcessUtils >> at
java.util.logging.LogManager.access$1500(LogManager.java:145)
PlatformProcessUtils >> at
java.util.logging.LogManager$RootLogger.accessCheckedHandlers(LogManager.java:1667)
PlatformProcessUtils >> at
java.util.logging.Logger.getHandlers(Logger.java:1777)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.findHandler(JavaLogger.java:411)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.configure(JavaLogger.java:241)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.(JavaLogger.java:181)
PlatformProcessUtils >> at
org.apache.ignite.logger.java.JavaLogger.(JavaLogger.java:135)
PlatformProcessUtils >> at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.initLogger(IgnitionEx.java:2454)
PlatformProcessUtils >> at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.initializeConfiguration(IgnitionEx.java:2122)
[jira] [Commented] (IGNITE-21180) Enable tests in ItTableRaftSnapshotsTest
[ https://issues.apache.org/jira/browse/IGNITE-21180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801171#comment-17801171 ] Roman Puchkovskiy commented on IGNITE-21180: ευχαριστώ! > Enable tests in ItTableRaftSnapshotsTest > > > Key: IGNITE-21180 > URL: https://issues.apache.org/jira/browse/IGNITE-21180 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > entriesKeepAppendedDuringSnapshotInstallation() turns out to be stable. > For nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(), a TODO has to be > changed to point to IGNITE-21181. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
>
> All in all, seems that it's required to substitute
>
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));{code}
> with
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable)
> -> {
> releaseTxLocks(txId);
> try {
> closeAllTransactionCursors(txId);
> } catch (Exception e) {
> LOG.warn("Unable to close cursor on primary
> replica expiration", e);
> }
> }));{code}
> Tests are trickey though.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Epic Link: IGNITE-21174 (was: IGNITE-15081)
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
>
> All in all, seems that it's required to substitute
>
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));{code}
> with
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable)
> -> {
> releaseTxLocks(txId);
> try {
> closeAllTransactionCursors(txId);
> } catch (Exception e) {
> LOG.warn("Unable to close cursor on primary
> replica expiration", e);
> }
> }));{code}
> Tests are trickey though.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21154) Improve InternalTable API
[
https://issues.apache.org/jira/browse/IGNITE-21154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21154:
-
Description: Currently, {{org.apache.ignite.internal.table.InternalTable}}
contains two methods, {{deleteAllExact}} and {{{}deleteExact{}}}, which compare
all columns of the stored and provided rows, subsequently deleting the rows if
their columns are equal. We need to introduce an option allowing specification
of only selected columns for equality checks. (was: Currently,
{{org.apache.ignite.internal.table.InternalTable}} contains two methods,
{{deleteAllExact}} and {{{}deleteExact{}}}, which compare all columns of the
stored and provided rows, subsequently deleting the rows if their columns are
equal. We need to introduce an option allowing specification of only selected
columns for equality checks.
Additionally, there is a need for methods capable of deleting rows in a
specific partition. This would involve implementing functionality like
{code:java}
CompletableFuture delete(BinaryRowEx keyRow, int partitionId,
@Nullable InternalTransaction tx);{code}
to enable targeted row deletion within an exact partition.)
> Improve InternalTable API
> -
>
> Key: IGNITE-21154
> URL: https://issues.apache.org/jira/browse/IGNITE-21154
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Ivan Gagarkin
>Priority: Major
> Labels: ignite-3
>
> Currently, {{org.apache.ignite.internal.table.InternalTable}} contains two
> methods, {{deleteAllExact}} and {{{}deleteExact{}}}, which compare all
> columns of the stored and provided rows, subsequently deleting the rows if
> their columns are equal. We need to introduce an option allowing
> specification of only selected columns for equality checks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Description:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
we release all tx locks
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
right in partition replica listeners. We even have corresponding helper method
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
All in all, seems that it's required to substitute
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));{code}
with
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) -> {
releaseTxLocks(txId);
try {
closeAllTransactionCursors(txId);
} catch (Exception e) {
LOG.warn("Unable to close cursor on primary replica
expiration", e);
}
}));{code}
Tests are trickey though.
was:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
we release all tx locks
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
right in partition replica listeners. We even have corresponding helper method
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so thi
[jira] [Updated] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Summary: Close local cursors on primary replica expiration (was: Handling
primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest)
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17615) Handling primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Description:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
we release all tx locks
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors
right in partition replica listeners. We even have corresponding helper method.
was:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
we release all tx locks
{{}}
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
{{}}
{{}}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors
right in partition replica listeners. We even have corresponding helper method.
> Handling primary replica changes on TxFinishReplicaRequest and
> TxCleanupReplicaRequest
> ---
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use
[jira] [Updated] (IGNITE-17615) Handling primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Description:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
we release all tx locks
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
right in partition replica listeners. We even have corresponding helper method
`org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
was:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
we release all tx locks
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors
right in partition replica listeners. We even have corresponding helper method.
> Handling primary replica changes on TxFinishReplicaRequest and
> TxCleanupReplicaRequest
> ---
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
[jira] [Updated] (IGNITE-17615) Handling primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17615:
-
Description:
h3. Motivation
According to our tx protocol, it’s impossible to commit a transaction if any of
the enlisted primary replicas have expired. It also means that there’s no sense
in preserving tx related volatile state such as locks and cursors. Pay
attention, that it’s still useful to preserve txnState in the txnStateLocalMap
because it will ease write intent resolution procedure. Locks release on
primary replica expiration was already implemented, so this ticket is only
about closing cursors on primary expiration.
h3. Definition of Done
* On primary replica expiration all RW-scoped cursors are closed.
h3. Implementation Notes
1.In
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
we release all tx locks
{{}}
{code:java}
futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
releaseTxLocks(txId)));
{code}
{{}}
{{}}
Seems reasonable to reuse same event to close the cursors. Worth mentioning
that given action should be asynchronous. I believe that we may do the cursors
close in partition striped pool. See StripedThreadPoolExecutor for more
details. Another option here is to introduce special dedicated cleanup thread
and use it instead. That will be a part of TX Resourse Cleanup design.
2. So, that was about when to close, let’s clarify what to close. Seems that
it’s trivial. We have
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors
right in partition replica listeners. We even have corresponding helper method.
> Handling primary replica changes on TxFinishReplicaRequest and
> TxCleanupReplicaRequest
> ---
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired
> we release all tx locks
> {{}}
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> {{}}
> {{}}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors
> right in partition replica listeners. We even have corresponding helper
> method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21093) MvccMessage removal
[ https://issues.apache.org/jira/browse/IGNITE-21093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-21093: -- Fix Version/s: 2.17 > MvccMessage removal > --- > > Key: IGNITE-21093 > URL: https://issues.apache.org/jira/browse/IGNITE-21093 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 50m > Remaining Estimate: 0h > > Remove MvccMessage > All classes in > modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/msg > are deleted: > * MvccAckRequestQueryId > * MvccAckRequestQueryCntr > * MvccAckRequestTxAndQueryCntr > * MvccAckRequestTxAndQueryId > * MvccActiveQueriesMessage > * MvccFutureResponse > * MvccMessage > * MvccQuerySnapshotRequest > * MvccRecoveryFinishedMessage > * MvccAckRequestTx > * MvccSnapshotResponse > * MvccSnapshotRequest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21093) MvccMessage removal
[ https://issues.apache.org/jira/browse/IGNITE-21093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801140#comment-17801140 ] Julia Bakulina commented on IGNITE-21093: - Hi [~av], could you please review the PR? [~shishkovilja] has approved the changes > MvccMessage removal > --- > > Key: IGNITE-21093 > URL: https://issues.apache.org/jira/browse/IGNITE-21093 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 50m > Remaining Estimate: 0h > > Remove MvccMessage > All classes in > modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/msg > are deleted: > * MvccAckRequestQueryId > * MvccAckRequestQueryCntr > * MvccAckRequestTxAndQueryCntr > * MvccAckRequestTxAndQueryId > * MvccActiveQueriesMessage > * MvccFutureResponse > * MvccMessage > * MvccQuerySnapshotRequest > * MvccRecoveryFinishedMessage > * MvccAckRequestTx > * MvccSnapshotResponse > * MvccSnapshotRequest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21093) MvccMessage removal
[
https://issues.apache.org/jira/browse/IGNITE-21093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801138#comment-17801138
]
Ignite TC Bot commented on IGNITE-21093:
{panel:title=Branch: [pull/11144/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11144/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7681719&buildTypeId=IgniteTests24Java8_RunAll]
> MvccMessage removal
> ---
>
> Key: IGNITE-21093
> URL: https://issues.apache.org/jira/browse/IGNITE-21093
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Remove MvccMessage
> All classes in
> modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/msg
> are deleted:
> * MvccAckRequestQueryId
> * MvccAckRequestQueryCntr
> * MvccAckRequestTxAndQueryCntr
> * MvccAckRequestTxAndQueryId
> * MvccActiveQueriesMessage
> * MvccFutureResponse
> * MvccMessage
> * MvccQuerySnapshotRequest
> * MvccRecoveryFinishedMessage
> * MvccAckRequestTx
> * MvccSnapshotResponse
> * MvccSnapshotRequest
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21087) VacuumTask removal
[ https://issues.apache.org/jira/browse/IGNITE-21087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21087: Summary: VacuumTask removal (was: VacuumTask and MvccTxEntry removal) > VacuumTask removal > -- > > Key: IGNITE-21087 > URL: https://issues.apache.org/jira/browse/IGNITE-21087 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 0.5h > Remaining Estimate: 0h > > Remove VacuumTask and MvccTxEntry. > Deleted classes: > * VacuumTask > * VacuumMetricsReducer > * VacuumMetrics > * PreviousQueries > * MvccTxEntry -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21018) Sql. Introduce cache for plan mapping
[ https://issues.apache.org/jira/browse/IGNITE-21018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21018: -- Attachment: ReferencesCacheTest.java > Sql. Introduce cache for plan mapping > - > > Key: IGNITE-21018 > URL: https://issues.apache.org/jira/browse/IGNITE-21018 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Attachments: ReferencesCache.java, ReferencesCacheTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > Mapping query on cluster topology is fairly expensive operation, because it > requires acquiring replicas per every partition a traversing a plan tree in > order to compute colocation of a query fragment. > This problem can be mitigated by introducing a cache for mapped queries. > Implementation notes: do not forget to invalidate cache when partition lease > got expired or logical topology has been changed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21018) Sql. Introduce cache for plan mapping
[ https://issues.apache.org/jira/browse/IGNITE-21018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21018: -- Attachment: ReferencesCache.java > Sql. Introduce cache for plan mapping > - > > Key: IGNITE-21018 > URL: https://issues.apache.org/jira/browse/IGNITE-21018 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Attachments: ReferencesCache.java > > Time Spent: 10m > Remaining Estimate: 0h > > Mapping query on cluster topology is fairly expensive operation, because it > requires acquiring replicas per every partition a traversing a plan tree in > order to compute colocation of a query fragment. > This problem can be mitigated by introducing a cache for mapped queries. > Implementation notes: do not forget to invalidate cache when partition lease > got expired or logical topology has been changed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21180) Enable tests in ItTableRaftSnapshotsTest
[ https://issues.apache.org/jira/browse/IGNITE-21180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21180: --- Description: entriesKeepAppendedDuringSnapshotInstallation() turns out to be stable. For nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(), a TODO has to be changed to point to IGNITE-21181. > Enable tests in ItTableRaftSnapshotsTest > > > Key: IGNITE-21180 > URL: https://issues.apache.org/jira/browse/IGNITE-21180 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > entriesKeepAppendedDuringSnapshotInstallation() turns out to be stable. > For nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(), a TODO has to be > changed to point to IGNITE-21181. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21181) Failure to resolve a primary replica after stopping a node
Roman Puchkovskiy created IGNITE-21181: -- Summary: Failure to resolve a primary replica after stopping a node Key: IGNITE-21181 URL: https://issues.apache.org/jira/browse/IGNITE-21181 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21180) Enable tests in ItTableRaftSnapshotsTest
[ https://issues.apache.org/jira/browse/IGNITE-21180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21180: --- Summary: Enable tests in ItTableRaftSnapshotsTest (was: Enable ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt) > Enable tests in ItTableRaftSnapshotsTest > > > Key: IGNITE-21180 > URL: https://issues.apache.org/jira/browse/IGNITE-21180 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21181) Failure to resolve a primary replica after stopping a node
[ https://issues.apache.org/jira/browse/IGNITE-21181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21181: --- Description: The scenario is that the cluster consists of 3 nodes (0, 1, 2). Primary replica of the sole partition is on node 0. Then node 0 is stopped and an attempt to do a put via node 2 is done. The partition still has majority, but the put results in the following: org.apache.ignite.tx.TransactionException: IGN-REP-5 TraceId:55c59c96-17d1-4efc-8e3c-cca81b8b41ad Failed to resolve the primary replica node [consistentId=itrst_ncisasiti_0] at org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$69(InternalTableImpl.java:1749) at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) at java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946) at java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266) at org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlist(InternalTableImpl.java:1739) at org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistWithRetry(InternalTableImpl.java:480) at org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistInTx(InternalTableImpl.java:301) at org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.upsert(InternalTableImpl.java:965) at org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$10(KeyValueViewImpl.java:196) at org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:111) at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) at org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:111) at org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102) at org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:193) at org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:185) at org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:257) at org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:253) at org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(ItTableRaftSnapshotsTest.java:473) This can be reproduced using ItTableRaftSnapshotsTest#nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(). > Failure to resolve a primary replica after stopping a node > -- > > Key: IGNITE-21181 > URL: https://issues.apache.org/jira/browse/IGNITE-21181 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The scenario is that the cluster consists of 3 nodes (0, 1, 2). Primary > replica of the sole partition is on node 0. Then node 0 is stopped and an > attempt to do a put via node 2 is done. The partition still has majority, but > the put results in the following: > > org.apache.ignite.tx.TransactionException: IGN-REP-5 > TraceId:55c59c96-17d1-4efc-8e3c-cca81b8b41ad Failed to resolve the primary > replica node [consistentId=itrst_ncisasiti_0] > > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$69(InternalTableImpl.java:1749) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946) > at > java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlist(InternalTableImpl.java:1739) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistWithRetry(InternalTableImpl.java:480) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistInTx(InternalTableImpl.java:301) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.upsert(InternalTableImpl.java:965) > at > org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$10(KeyValueViewImpl.java:196) > at > org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:111) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) > at > org.apache.ignite.
[jira] [Updated] (IGNITE-21180) Enable ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt
[ https://issues.apache.org/jira/browse/IGNITE-21180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21180: --- Summary: Enable ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt (was: Enable tests in ItTableRaftSnapshotsTest) > Enable > ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt > - > > Key: IGNITE-21180 > URL: https://issues.apache.org/jira/browse/IGNITE-21180 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21180) Enable tests in ItTableRaftSnapshotsTest
Roman Puchkovskiy created IGNITE-21180: -- Summary: Enable tests in ItTableRaftSnapshotsTest Key: IGNITE-21180 URL: https://issues.apache.org/jira/browse/IGNITE-21180 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21179) Consider abandoned as not only lack of coordinator but also lack of commitPartition
[
https://issues.apache.org/jira/browse/IGNITE-21179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21179:
-
Description:
h3. Motivation
According to
[IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Coordinatorfailure]
it's required to have fail-fast tx failure only in case of both coordinator
and commitPartition unavailability. In IEP given state marked as "hanging"
{quote}Commit partition group nodes have lost the majority. In this case the
state of txn is unknown. We need to wait until the majority is restored and
until this happens all locks are remaining held. We should mark such
transactions as “hanging”. All subsequent transactions which are trying to take
a lock and see the locker tx in the hanging state are immediately failed with a
message like: “Failed to take a lock because the previous locker state is
unknown ” + tx info.
{quote}
However, currently transaction will immediately fail event if commitCartition
is up and running just if coordinator is missing. It is worth to adjust the
implementation to the logic specified in PR.
h3. Definition of Done
* We should mark tx as abandoned if both coordinator and commitPartition are
missing.
* If tx is not abandoned (coordinator is missing but commitPartition is
considered alive (e.g. there is a corresponding primary replica)) then a
transaction that faced lock conflict should behave according to the deadlock
prevention rules.
* If tx is maked as abandoned then transaction that faced lock conflict fail
fast with “Failed to take a lock because the previous locker state is unknown ”
+ tx info.
> Consider abandoned as not only lack of coordinator but also lack of
> commitPartition
> ---
>
> Key: IGNITE-21179
> URL: https://issues.apache.org/jira/browse/IGNITE-21179
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Coordinatorfailure]
> it's required to have fail-fast tx failure only in case of both coordinator
> and commitPartition unavailability. In IEP given state marked as "hanging"
> {quote}Commit partition group nodes have lost the majority. In this case the
> state of txn is unknown. We need to wait until the majority is restored and
> until this happens all locks are remaining held. We should mark such
> transactions as “hanging”. All subsequent transactions which are trying to
> take a lock and see the locker tx in the hanging state are immediately failed
> with a message like: “Failed to take a lock because the previous locker state
> is unknown ” + tx info.
> {quote}
> However, currently transaction will immediately fail event if commitCartition
> is up and running just if coordinator is missing. It is worth to adjust the
> implementation to the logic specified in PR.
> h3. Definition of Done
> * We should mark tx as abandoned if both coordinator and commitPartition are
> missing.
> * If tx is not abandoned (coordinator is missing but commitPartition is
> considered alive (e.g. there is a corresponding primary replica)) then a
> transaction that faced lock conflict should behave according to the deadlock
> prevention rules.
> * If tx is maked as abandoned then transaction that faced lock conflict fail
> fast with “Failed to take a lock because the previous locker state is unknown
> ” + tx info.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21179) Consider abandoned as not only lack of coordinator but also lack of commitPartition
Alexander Lapin created IGNITE-21179: Summary: Consider abandoned as not only lack of coordinator but also lack of commitPartition Key: IGNITE-21179 URL: https://issues.apache.org/jira/browse/IGNITE-21179 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove PendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Summary: Remove PendingRows collection (was: Remove pendingRows collection) > Remove PendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > # Instead of using PendingRows retrieve rowIds from > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, > org.apache.ignite.internal.table.distributed.replicator.PendingRows should be > removed. > # It also means that [Excessive full partition scan on node > start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. > It worth mentioning that now it's safe to eliminate pendingRows population on > start because we have full lazy write intent resolution. > # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to > get partitionId from rowId, thus we may remove > `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. > h3. Definition of Done > * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. > * On receiving TxCleanupMessage node retrieves rowIds from within > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by > RowId#partitionId and sends local writeIntentSwitchReplicaRequest. > * org.apache.ignite.internal.table.distributed.replicator.PendingRow is > removed. > * `Excessive full partition scan on node start` that was used to populate > PendingRow also removed. Corresponding ticket is closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove pendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Epic Link: IGNITE-21174 > Remove pendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > # Instead of using PendingRows retrieve rowIds from > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, > org.apache.ignite.internal.table.distributed.replicator.PendingRows should be > removed. > # It also means that [Excessive full partition scan on node > start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. > It worth mentioning that now it's safe to eliminate pendingRows population on > start because we have full lazy write intent resolution. > # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to > get partitionId from rowId, thus we may remove > `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. > h3. Definition of Done > * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. > * On receiving TxCleanupMessage node retrieves rowIds from within > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by > RowId#partitionId and sends local writeIntentSwitchReplicaRequest. > * org.apache.ignite.internal.table.distributed.replicator.PendingRow is > removed. > * `Excessive full partition scan on node start` that was used to populate > PendingRow also removed. Corresponding ticket is closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove pendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Description: h3. Motivation According to [~ascherbakov] is useful to rework tx cleanup flow in a following way: # Instead of using PendingRows retrieve rowIds from `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, org.apache.ignite.internal.table.distributed.replicator.PendingRows should be removed. # It also means that [Excessive full partition scan on node start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. It worth mentioning that now it's safe to eliminate pendingRows population on start because we have full lazy write intent resolution. # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to get partitionId from rowId, thus we may remove `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. h3. Definition of Done * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. * On receiving TxCleanupMessage node retrieves rowIds from within `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by RowId#partitionId and sends local writeIntentSwitchReplicaRequest. * org.apache.ignite.internal.table.distributed.replicator.PendingRow is removed. * `Excessive full partition scan on node start` that was used to populate PendingRow also removed. Corresponding ticket is closed. was: According to [~ascherbakov] is useful to rework tx cleanup flow in a following way: On receiving cleanupRequest with txId (enlisted partition IDs should be removed from the parameters list) # Node thought lockManager `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` retrieves all enlisted rowIds ## Unlock them, and all other corresponding locks of course. ## Group them on per partition basis. # for each rowId sends wiSwitchCmd. > Remove pendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > # Instead of using PendingRows retrieve rowIds from > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, > org.apache.ignite.internal.table.distributed.replicator.PendingRows should be > removed. > # It also means that [Excessive full partition scan on node > start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. > It worth mentioning that now it's safe to eliminate pendingRows population on > start because we have full lazy write intent resolution. > # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to > get partitionId from rowId, thus we may remove > `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. > h3. Definition of Done > * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. > * On receiving TxCleanupMessage node retrieves rowIds from within > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by > RowId#partitionId and sends local writeIntentSwitchReplicaRequest. > * org.apache.ignite.internal.table.distributed.replicator.PendingRow is > removed. > * `Excessive full partition scan on node start` that was used to populate > PendingRow also removed. Corresponding ticket is closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove pendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove pendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > h3. Motivation > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > # Instead of using PendingRows retrieve rowIds from > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, > org.apache.ignite.internal.table.distributed.replicator.PendingRows should be > removed. > # It also means that [Excessive full partition scan on node > start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. > It worth mentioning that now it's safe to eliminate pendingRows population on > start because we have full lazy write intent resolution. > # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to > get partitionId from rowId, thus we may remove > `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. > h3. Definition of Done > * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. > * On receiving TxCleanupMessage node retrieves rowIds from within > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by > RowId#partitionId and sends local writeIntentSwitchReplicaRequest. > * org.apache.ignite.internal.table.distributed.replicator.PendingRow is > removed. > * `Excessive full partition scan on node start` that was used to populate > PendingRow also removed. Corresponding ticket is closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove pendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Labels: ignite-3 (was: ) > Remove pendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > # Instead of using PendingRows retrieve rowIds from > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap`. Thus, > org.apache.ignite.internal.table.distributed.replicator.PendingRows should be > removed. > # It also means that [Excessive full partition scan on node > start|https://issues.apache.org/jira/browse/IGNITE-18502] will be resolved. > It worth mentioning that now it's safe to eliminate pendingRows population on > start because we have full lazy write intent resolution. > # Besides retrieving rowIds from HeapLockManager#txMap it's also possible to > get partitionId from rowId, thus we may remove > `org.apache.ignite.internal.tx.message.TxCleanupMessage#groups`. > h3. Definition of Done > * org.apache.ignite.internal.tx.message.TxCleanupMessage#group is removed. > * On receiving TxCleanupMessage node retrieves rowIds from within > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` group them by > RowId#partitionId and sends local writeIntentSwitchReplicaRequest. > * org.apache.ignite.internal.table.distributed.replicator.PendingRow is > removed. > * `Excessive full partition scan on node start` that was used to populate > PendingRow also removed. Corresponding ticket is closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21178) ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21178:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is flaky
> ---
>
> Key: IGNITE-21178
> URL: https://issues.apache.org/jira/browse/IGNITE-21178
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> This test fails sometimes with the following error:
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=3.0, cpu=306310.2111592855, memory=4.0, io=0.0,
> network=4.0], id = 4386
> IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
> network=0.0], id = 4385
> IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
> requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
> Expected: a string contains once ".*IgniteIndexScan\\(table=\\[\\[PUBLIC,
> TEST\\]\\], tableId=\\[.*\\], index=\\[TEST_IDX\\].*\\)"
> but: was "IgniteExchange(distribution=[single]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=3.0, cpu=306310.2111592855,
> memory=4.0, io=0.0, network=4.0], id = 4386
> IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
> network=0.0], id = 4385
> IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
> requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21178) ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21178:
-
Labels: ignite-3 (was: )
> ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is flaky
> ---
>
> Key: IGNITE-21178
> URL: https://issues.apache.org/jira/browse/IGNITE-21178
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> This test fails sometimes with the following error:
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=3.0, cpu=306310.2111592855, memory=4.0, io=0.0,
> network=4.0], id = 4386
> IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
> network=0.0], id = 4385
> IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
> requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
> Expected: a string contains once ".*IgniteIndexScan\\(table=\\[\\[PUBLIC,
> TEST\\]\\], tableId=\\[.*\\], index=\\[TEST_IDX\\].*\\)"
> but: was "IgniteExchange(distribution=[single]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=3.0, cpu=306310.2111592855,
> memory=4.0, io=0.0, network=4.0], id = 4386
> IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
> network=0.0], id = 4385
> IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
> requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21178) ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is flaky
Aleksandr Polovtcev created IGNITE-21178:
Summary: ItSqlSynchronousApiTest#checkMixedTransactionsForIndex is
flaky
Key: IGNITE-21178
URL: https://issues.apache.org/jira/browse/IGNITE-21178
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
This test fails sometimes with the following error:
{noformat}
java.lang.AssertionError: Invalid plan:
IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=3.0, cpu=306310.2111592855, memory=4.0, io=0.0,
network=4.0], id = 4386
IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
network=0.0], id = 4385
IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
Expected: a string contains once ".*IgniteIndexScan\\(table=\\[\\[PUBLIC,
TEST\\]\\], tableId=\\[.*\\], index=\\[TEST_IDX\\].*\\)"
but: was "IgniteExchange(distribution=[single]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=3.0, cpu=306310.2111592855,
memory=4.0, io=0.0, network=4.0], id = 4386
IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=2.0, cpu=296310.2111592855, memory=4.0, io=0.0,
network=0.0], id = 4385
IgniteTableScan(table=[[PUBLIC, TEST]], tableId=[14],
requiredColumns=[{1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 4384
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21176) Remove pendingRows collection
[ https://issues.apache.org/jira/browse/IGNITE-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21176: - Summary: Remove pendingRows collection (was: Transactions: rework cleanup + switchWriteInent pipeline) > Remove pendingRows collection > - > > Key: IGNITE-21176 > URL: https://issues.apache.org/jira/browse/IGNITE-21176 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > > According to [~ascherbakov] is useful to rework tx cleanup flow in a > following way: > On receiving cleanupRequest with txId (enlisted partition IDs should be > removed from the parameters list) > # Node thought lockManager > `org.apache.ignite.internal.tx.impl.HeapLockManager#txMap` retrieves all > enlisted rowIds > ## Unlock them, and all other corresponding locks of course. > ## Group them on per partition basis. > # for each rowId sends wiSwitchCmd. -- This message was sent by Atlassian Jira (v8.20.10#820010)
