[jira] [Created] (IGNITE-23284) SQL text in server logs on errors
Alexander Belyak created IGNITE-23284: - Summary: SQL text in server logs on errors Key: IGNITE-23284 URL: https://issues.apache.org/jira/browse/IGNITE-23284 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak # start and init 1 node cluster # execute query: *select count(*) from users where login='alex' and password='123'* The problem is that server logs contain an error like: {code:java} 2024-09-26 08:57:05:391 + [INFO][%poc-tester-SERVER-172.24.1.2-id-0%sql-execution-pool-1][JdbcQueryEventHandlerImpl] Exception while executing query [query=select count(*) from users where login='alex' and password='123'] org.apache.ignite.sql.SqlException: IGN-SQL-4 TraceId:deb3621b-1ecf-49b1-a072-fc77ddbf579b Failed to validate query. From line 1, column 22 to line 1, column 26: Object 'USERS' not found {code} If the user's application retries the query on any error it'll lead to log overflow and rotation. It makes logs useless for DBA. Also, it's not safe to log query text, it could contain sensitive information. Let's move messages like this (low priority messages with well known user errors like a bad query) into a separate log files to let them rotate individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23264) Stdout for ignite3db
Alexander Belyak created IGNITE-23264: - Summary: Stdout for ignite3db Key: IGNITE-23264 URL: https://issues.apache.org/jira/browse/IGNITE-23264 Project: Ignite Issue Type: Bug Components: general Affects Versions: 3.0 Reporter: Alexander Belyak Empty stdout after running {code:java} cd ignite3-db-3.0.0-SNAPSHOT/bin/ root:/root/ignite3-3.0.0-SNAPSHOT/ignite3-db-3.0.0-SNAPSHOT/bin$ ./ignite3db {code} confuses some of the users. Lets add some message like: `{color:#1d1c1d}Node started, see log/ignite3db-0.log for logs.` {color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19701) Type exception on insert into uuid columns with gen_random_uuid
[ https://issues.apache.org/jira/browse/IGNITE-19701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880544#comment-17880544 ] Alexander Belyak commented on IGNITE-19701: --- Yes, now it works. Thanks. > Type exception on insert into uuid columns with gen_random_uuid > --- > > Key: IGNITE-19701 > URL: https://issues.apache.org/jira/browse/IGNITE-19701 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Step to reproduce: > {noformat} > create table tdd(a uuid default gen_random_uuid, b int, primary key (a) ); > insert into tdd(b) values(22) > {noformat} > Expected result: row with autogenerated primary key a inserted > Actual result: > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=insert > into tdd(b) values(22)]. Error message:Query remote fragment execution > failed: nodeName=DropColumnsTest_cluster_1, > queryId=e0a9b944-74a5-4d9d-a4a9-7962cb821c81, fragmentId=20, > originalMessage=storageType is class java.util.UUID value must also be class > java.util.UUID but it was: 1726917f-f47f-4ccc-94a0-59ac518e101b{noformat} > It is possibly to insert row with generated UUID: > {noformat} > insert into tdd(a, b) values('1726917f-f47f-4ccc-94a0-59ac518e101b', > 22){noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22659) Error floods on logs
Alexander Belyak created IGNITE-22659: - Summary: Error floods on logs Key: IGNITE-22659 URL: https://issues.apache.org/jira/browse/IGNITE-22659 Project: Ignite Issue Type: Bug Components: general Affects Versions: 3.0 Reporter: Alexander Belyak Each particular error writes it's own log message, even if there is 1000s of them already. For example, in two nodes cluster if we kill one node we get: *1857* of "[{*}ERROR{*}][%ClusterFailover2NodesTest_cluster_0%JRaft-Common-Executor-0][AbstractClientService] Fail to connect ClusterFailover2NodesTest_cluster_1, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.120.1.2:3345." *160 000+* {*}WARNING{*}s of "Recoverable error during the request occurred (will be retried on the randomly selected node)" In a minute! It makes log system useless, because original error messages would be rotated when somebody have change to analyze it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22647) Deb package doesn't have dependency to the Java
Alexander Belyak created IGNITE-22647: - Summary: Deb package doesn't have dependency to the Java Key: IGNITE-22647 URL: https://issues.apache.org/jira/browse/IGNITE-22647 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 3.0 Reporter: Alexander Belyak Deb distributive doesn't have dependency to any Java runtime: {noformat} dpkg -I /home/abelyak/gg/ignite-3/packaging/db/build/distributions/ignite3-db_3.0.0~SNAPSHOT_all.deb new Debian package, version 2.0. size 129474952 bytes: control archive=8563 bytes. 22 bytes, 1 lines conffiles 280 bytes, 11 lines control 17413 bytes, 197 lines md5sums 6631 bytes, 185 lines * postinst #!/bin/sh 4979 bytes, 143 lines * postrm #!/bin/sh 5000 bytes, 141 lines * preinst #!/bin/sh 4890 bytes, 137 lines * prerm #!/bin/sh Package: ignite3-db Source: ignite3-db Version: 3.0.0~SNAPSHOT Section: System Environment/Daemons Priority: optional Architecture: all Installed-Size: 133198 Maintainer: abelyak Description: ignite3-db This package will install Apache Ignite Homepage: https://ignite.apache.org {noformat} So one can install .deb package to a new host and get broken system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21537) Connection refused exception contains 800 lines
[ https://issues.apache.org/jira/browse/IGNITE-21537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846735#comment-17846735 ] Alexander Belyak commented on IGNITE-21537: --- Still getting 150+ lines like: {noformat} 2024-05-15 17:44:22:401 + [WARNING][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-AppendEntries-Processor-1][Replicator] Fail to issue RPC to poc-tester-SERVER-172.24.1.2-id-0, consecutiveErrorTimes=100, error=Status[EINTERNAL<1004>: Check connection[poc-tester-SERVER-172.24.1.2-id-0] fail and try to create new one] 2024-05-15 17:44:22:513 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:523 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-3][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:635 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:644 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-6][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:757 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:767 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:878 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-0][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:22:900 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:000 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-4][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:021 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:022 + [WARNING][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-AppendEntries-Processor-1][Replicator] Fail to issue RPC to poc-tester-SERVER-172.24.1.2-id-0, consecutiveErrorTimes=110, error=Status[EINTERNAL<1004>: Check connection[poc-tester-SERVER-172.24.1.2-id-0] fail and try to create new one] 2024-05-15 17:44:23:122 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:144 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-3][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:244 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. 2024-05-15 17:44:23:265 + [ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService] Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.24.1.2:3344. {noformat} It makes server logs difficult to read. > Conn
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[ https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-22213: -- Description: 1) Start cluster, 2) Init cluster, 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} {color:#1d1c1d}After cluster is fully initialized (logical topology meets expectations), it fixes.{color} {color:#1d1c1d}If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing.{color} was: 1) Start cluster, 2) Init cluster, 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} {color:#1d1c1d}After cluster is fully initialized (logical topology meets expectations), it fixes.{color} {color:#1d1c1d}If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing.{color} > Schema PUBLIC not found for a short time right after start using JDBC > - > > Key: IGNITE-22213 > URL: https://issues.apache.org/jira/browse/IGNITE-22213 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > > 1) Start cluster, > 2) Init cluster, > 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} > 4) Create table > Expected result: table successfully created > Actual result: error > {noformat} > java.sql.SQLException: Schema not found [schemaName=PUBLIC] at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} > {color:#1d1c1d}After cluster is fully initialized (logical topology meets > expectations), it fixes.{color} > {color:#1d1c1d}If the cluster is not ready to process the connection - it > shouldn't accept it. Or wait until metadata schema available on request > processing.{color} > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[ https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-22213: -- Priority: Major (was: Minor) > Schema PUBLIC not found for a short time right after start using JDBC > - > > Key: IGNITE-22213 > URL: https://issues.apache.org/jira/browse/IGNITE-22213 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > 1) Start cluster, > 2) Init cluster, > 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} > 4) Create table > Expected result: table successfully created > Actual result: error > {noformat} > java.sql.SQLException: Schema not found [schemaName=PUBLIC] at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} > {color:#1d1c1d}After cluster is fully initialized (logical topology meets > expectations), it fixes.{color} > {color:#1d1c1d}If the cluster is not ready to process the connection - it > shouldn't accept it. Or wait until metadata schema available on request > processing.{color} > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[ https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-22213: -- Description: 1) Start cluster, 2) Init cluster, 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} {color:#1d1c1d}After cluster is fully initialized (logical topology meets expectations), it fixes.{color} {color:#1d1c1d}If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing.{color} was: 1) Start cluster, 2) Activate, 3) Connect using JDBC 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} {color:#1d1c1d}After cluster is fully initialized (logical topology meets expectations), it fixes.{color} {color:#1d1c1d}If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing.{color} > Schema PUBLIC not found for a short time right after start using JDBC > - > > Key: IGNITE-22213 > URL: https://issues.apache.org/jira/browse/IGNITE-22213 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > > 1) Start cluster, > 2) Init cluster, > 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color} > 4) Create table > Expected result: table successfully created > Actual result: error > {noformat} > java.sql.SQLException: Schema not found [schemaName=PUBLIC] at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} > {color:#1d1c1d}After cluster is fully initialized (logical topology meets > expectations), it fixes.{color} > {color:#1d1c1d}If the cluster is not ready to process the connection - it > shouldn't accept it. Or wait until metadata schema available on request > processing.{color} > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[ https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-22213: -- Description: 1) Start cluster, 2) Activate, 3) Connect using JDBC 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} {color:#1d1c1d}After cluster is fully initialized (logical topology meets expectations), it fixes.{color} {color:#1d1c1d}If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing.{color} was: 1) Start cluster, 2) Activate, 3) Connect using JDBC 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} After a few seconds, it fixes. If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing. > Schema PUBLIC not found for a short time right after start using JDBC > - > > Key: IGNITE-22213 > URL: https://issues.apache.org/jira/browse/IGNITE-22213 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > > 1) Start cluster, > 2) Activate, > 3) Connect using JDBC > 4) Create table > Expected result: table successfully created > Actual result: error > {noformat} > java.sql.SQLException: Schema not found [schemaName=PUBLIC] at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} > {color:#1d1c1d}After cluster is fully initialized (logical topology meets > expectations), it fixes.{color} > {color:#1d1c1d}If the cluster is not ready to process the connection - it > shouldn't accept it. Or wait until metadata schema available on request > processing.{color} > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
Alexander Belyak created IGNITE-22213: - Summary: Schema PUBLIC not found for a short time right after start using JDBC Key: IGNITE-22213 URL: https://issues.apache.org/jira/browse/IGNITE-22213 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak 1) Start cluster, 2) Activate, 3) Connect using JDBC 4) Create table Expected result: table successfully created Actual result: error {noformat} java.sql.SQLException: Schema not found [schemaName=PUBLIC] at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat} After a few seconds, it fixes. If the cluster is not ready to process the connection - it shouldn't accept it. Or wait until metadata schema available on request processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22123) Critical thread blocked on 2 node cluster with intensive create tables
Alexander Belyak created IGNITE-22123: - Summary: Critical thread blocked on 2 node cluster with intensive create tables Key: IGNITE-22123 URL: https://issues.apache.org/jira/browse/IGNITE-22123 Project: Ignite Issue Type: Bug Affects Versions: 3.0 Reporter: Alexander Belyak # Start 2 nodes cluster (I use single host for both nodes) # Connect to the first node and do in cycle: ## create table (different 8 columns PK) ## insert a few rows in it ## select a row from table Expected result: test pass without errors Actual result: client get: {noformat} 16:45:20.253 [junit-timeout-thread-119] INFO o.g.a.t.teststeps.ThinClientSteps - Query: drop table if exists eight_different_types_TINYINT_INTEGER_FLOAT_TINYINT_TINYINT_TINYINT_TINYINT_TINYINT Apr 26, 2024 4:45:20 PM org.apache.ignite.internal.logger.IgniteLogger logInternal INFO: Partition assignment change notification received [remoteAddress=localhost:10800] 16:45:20.266 [junit-timeout-thread-119] INFO o.g.a.t.teststeps.ThinClientSteps - Query: create table eight_different_types_TINYINT_INTEGER_FLOAT_TINYINT_TINYINT_TINYINT_TINYINT_TINYINT(keyTINYINT0 TINYINT not null, keyINTEGER1 INTEGER not null, keyFLOAT2 FLOAT not null, keyTINYINT3 TINYINT not null, keyTINYINT4 TINYINT not null, keyTINYINT5 TINYINT not null, keyTINYINT6 TINYINT not null, keyTINYINT7 TINYINT not null, val INTEGER not null, primary key (keyTINYINT0, keyINTEGER1, keyFLOAT2, keyTINYINT3, keyTINYINT4, keyTINYINT5, keyTINYINT6, keyTINYINT7)) 16:45:28.570 [junit-timeout-thread-119] INFO o.g.a.t.teststeps.ThinClientSteps - Query: insert into eight_different_types_TINYINT_INTEGER_FLOAT_TINYINT_TINYINT_TINYINT_TINYINT_TINYINT(keyTINYINT0, keyINTEGER1, keyFLOAT2, keyTINYINT3, keyTINYINT4, keyTINYINT5, keyTINYINT6, keyTINYINT7, val) values (-96, 25781810, 5.0, -93, -92, -91, -90, -89, 116513)org.apache.ignite.sql.SqlException: IGN-PLACEMENTDRIVER-1 TraceId:e21f4eb1-4ecb-4ea2-aaf7-62a08b677f20 Failed to get the primary replica [tablePartitionId=85_part_18, awaitTimestamp=HybridTimestamp [physical=2024-04-26 16:45:28:599 +0300, logical=0, composite=112337821931864064]] at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710) at org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765) at org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699) at org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525) at org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634) at org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476) at org.apache.ignite.internal.client.sql.ClientSql.execute(ClientSql.java:94) at org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.lambda$executeQuery$0(ThinClientSteps.java:61) at io.qameta.allure.Allure.lambda$step$1(Allure.java:127) at io.qameta.allure.Allure.step(Allure.java:181) at io.qameta.allure.Allure.step(Allure.java:125) at org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.executeQuery(ThinClientSteps.java:61) at org.gridgain.ai3tests.tests.PrimaryKeyConstraintsTest.testTypes(PrimaryKeyConstraintsTest.java:167) at org.gridgain.ai3tests.tests.PrimaryKeyConstraintsTest.test8Columns(PrimaryKeyConstraintsTest.java:120) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at io.qameta.allure.junit5.AllureJunit5.interceptTestTemplateMethod(AllureJunit5.java:59) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.util.concurrent.CompletionException: org.apache.ignite.sql.SqlException: IGN-PLACEMENTDRIVER-1 TraceId:e21f4eb1-4ecb-4ea2-aaf7-62a08b677f20 Failed to get the primary replica [tablePartitionId=85_part_18, awaitTimestamp=HybridTimestamp [physical=2024-04-26 16:45:28:599 +0300, logical=0, composite=112337821931864064]] at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870) at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2094)
[jira] [Commented] (IGNITE-21874) Log Java&OS versions to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832171#comment-17832171 ] Alexander Belyak commented on IGNITE-21874: --- Related to the IGNITE-19383 > Log Java&OS versions to the server log at startup > - > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21874) Log Java&OS versions to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832171#comment-17832171 ] Alexander Belyak edited comment on IGNITE-21874 at 3/29/24 10:53 AM: - Related to the IGNITE-19383 Add commit hash to the server log was (Author: berkov): Related to the IGNITE-19383 > Log Java&OS versions to the server log at startup > - > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19383) Add commit hash to the server log
[ https://issues.apache.org/jira/browse/IGNITE-19383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19383: -- Summary: Add commit hash to the server log (was: Add commit hash to log) > Add commit hash to the server log > - > > Key: IGNITE-19383 > URL: https://issues.apache.org/jira/browse/IGNITE-19383 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Let's add commit hash into the log message: > > {code:java} > INFO: > # ___ __ > ### / | _ _ / /_ ___ > # # / /| | / __ \ / __ `// ___// __ \ / _ \ > ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ > # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ > ### ## /_/ > _ __ _ > # ## / _/ _ (_)/ /_ ___ |__ / > ### # / / / __ `// __ \ / // __// _ \ /_ < > # # _/ / / /_/ // / / // // /_ / ___/ ___/ / > ## /___/ \__, //_/ /_//_/ \__/ \___/ // > ## // > Apache Ignite ver. 3.0.0-SNAPSHOT > {code} > after the version like in the previous version > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19383) Add commit hash to log
[ https://issues.apache.org/jira/browse/IGNITE-19383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832170#comment-17832170 ] Alexander Belyak commented on IGNITE-19383: --- Related to the IGNITE-21874 > Add commit hash to log > -- > > Key: IGNITE-19383 > URL: https://issues.apache.org/jira/browse/IGNITE-19383 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Let's add commit hash into the log message: > > {code:java} > INFO: > # ___ __ > ### / | _ _ / /_ ___ > # # / /| | / __ \ / __ `// ___// __ \ / _ \ > ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ > # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ > ### ## /_/ > _ __ _ > # ## / _/ _ (_)/ /_ ___ |__ / > ### # / / / __ `// __ \ / // __// _ \ /_ < > # # _/ / / /_/ // / / // // /_ / ___/ ___/ / > ## /___/ \__, //_/ /_//_/ \__/ \___/ // > ## // > Apache Ignite ver. 3.0.0-SNAPSHOT > {code} > after the version like in the previous version > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log Java&OS versions to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21874: -- Summary: Log Java&OS versions to the server log at startup (was: Log versions (java, ignite) to the server log at startup) > Log Java&OS versions to the server log at startup > - > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > 2) Product version WITH *commit hash* > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19383) Add commit hash to log
[ https://issues.apache.org/jira/browse/IGNITE-19383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19383: -- Description: Let's add commit hash into the log message: {code:java} INFO: # ___ __ ### / | _ _ / /_ ___ # # / /| | / __ \ / __ `// ___// __ \ / _ \ ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ ### ## /_/ _ __ _ # ## / _/ _ (_)/ /_ ___ |__ / ### # / / / __ `// __ \ / // __// _ \ /_ < # # _/ / / /_/ // / / // // /_ / ___/ ___/ / ## /___/ \__, //_/ /_//_/ \__/ \___/ // ## // Apache Ignite ver. 3.0.0-SNAPSHOT {code} after the version like in the previous version AI2 (version and commit has): {noformat} ver. 2.16.0#20231215-sha1:7bde6a42{noformat} AI3 (only version): {noformat} Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} was: Let's add commit hash into the log message: {code:java} INFO: # ___ __ ### / | _ _ / /_ ___ # # / /| | / __ \ / __ `// ___// __ \ / _ \ ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ ### ## /_/ _ __ _ # ## / _/ _ (_)/ /_ ___ |__ / ### # / / / __ `// __ \ / // __// _ \ /_ < # # _/ / / /_/ // / / // // /_ / ___/ ___/ / ## /___/ \__, //_/ /_//_/ \__/ \___/ // ## // Apache Ignite ver. 3.0.0-SNAPSHOT {code} after the version > Add commit hash to log > -- > > Key: IGNITE-19383 > URL: https://issues.apache.org/jira/browse/IGNITE-19383 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Let's add commit hash into the log message: > > {code:java} > INFO: > # ___ __ > ### / | _ _ / /_ ___ > # # / /| | / __ \ / __ `// ___// __ \ / _ \ > ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ > # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ > ### ## /_/ > _ __ _ > # ## / _/ _ (_)/ /_ ___ |__ / > ### # / / / __ `// __ \ / // __// _ \ /_ < > # # _/ / / /_/ // / / // // /_ / ___/ ___/ / > ## /___/ \__, //_/ /_//_/ \__/ \___/ // > ## // > Apache Ignite ver. 3.0.0-SNAPSHOT > {code} > after the version like in the previous version > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log Java&OS versions to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21874: -- Description: We need to log some environments to the server log. 1) *OS* and {*}Java version{*}: AI2: {noformat} OS: Linux 5.15.0-100-generic amd64 [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} AI3: {code:java} // Nothing {code} was: We need to log some environments to the server log. 1) *OS* and {*}Java version{*}: AI2: {noformat} OS: Linux 5.15.0-100-generic amd64 [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} AI3: {code:java} // Nothing {code} 2) Product version WITH *commit hash* AI2 (version and commit has): {noformat} ver. 2.16.0#20231215-sha1:7bde6a42{noformat} AI3 (only version): {noformat} Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > Log Java&OS versions to the server log at startup > - > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21874: -- Labels: ignite-3 (was: ) > Log versions (java, ignite) to the server log at startup > > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > 2) Product version WITH *commit hash* > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
[ https://issues.apache.org/jira/browse/IGNITE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21874: -- Description: We need to log some environments to the server log. 1) *OS* and {*}Java version{*}: AI2: {noformat} OS: Linux 5.15.0-100-generic amd64 [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} AI3: {code:java} // Nothing {code} 2) Product version WITH *commit hash* AI2 (version and commit has): {noformat} ver. 2.16.0#20231215-sha1:7bde6a42{noformat} AI3 (only version): {noformat} Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} was: We need to log some environments to the server log. 1) *OS* and {*}Java version{*}: AI2: {noformat} OS: Linux 5.15.0-100-generic amd64 [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} AI3: {code:java} // Nothing {code} 2) Product version WITH *commit hash* AI2 (version and commit has): {noformat} ver. 2.16.0#20231215-sha1:7bde6a42{noformat} AI3 (only version): {noformat} Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > Log versions (java, ignite) to the server log at startup > > > Key: IGNITE-21874 > URL: https://issues.apache.org/jira/browse/IGNITE-21874 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Alexander Belyak >Priority: Major > > We need to log some environments to the server log. > 1) *OS* and {*}Java version{*}: > AI2: > {noformat} > OS: Linux 5.15.0-100-generic amd64 > [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 > Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} > AI3: > {code:java} > // Nothing > {code} > 2) Product version WITH *commit hash* > AI2 (version and commit has): > {noformat} > ver. 2.16.0#20231215-sha1:7bde6a42{noformat} > AI3 (only version): > {noformat} > Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21874) Log versions (java, ignite) to the server log at startup
Alexander Belyak created IGNITE-21874: - Summary: Log versions (java, ignite) to the server log at startup Key: IGNITE-21874 URL: https://issues.apache.org/jira/browse/IGNITE-21874 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 3.0.0-alpha5 Reporter: Alexander Belyak We need to log some environments to the server log. 1) *OS* and {*}Java version{*}: AI2: {noformat} OS: Linux 5.15.0-100-generic amd64 [17:54:06] VM information: Java(TM) SE Runtime Environment 18.0.1.1+2-6 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 18.0.1.1+2-6{noformat} AI3: {code:java} // Nothing {code} 2) Product version WITH *commit hash* AI2 (version and commit has): {noformat} ver. 2.16.0#20231215-sha1:7bde6a42{noformat} AI3 (only version): {noformat} Apache Ignite ver. 3.0.0-SNAPSHOT{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[ https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831771#comment-17831771 ] Alexander Belyak commented on IGNITE-20731: --- [~slava.koptilin] I'm unable to reproduce it on a fresh main branch. > Exception "The primary replica has changed" on big amount of rows > - > > Key: IGNITE-20731 > URL: https://issues.apache.org/jira/browse/IGNITE-20731 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > *Steps to reproduce:* > 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m" > 2. Execute > {code:java} > create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50) > not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, > column_4 VARCHAR(50) not null, primary key (id)) {code} > 3. Insert rows into table up to 1 000 000 rows. > *Expected result:* > Rows are inserted. > *Actual result:* > After 733000 rows the exception is thrown. > Client: > {code:java} > java.sql.BatchUpdateException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155) > {code} > Server: > {code:java} > 2023-10-23 13:47:31:529 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_12] > 2023-10-23 13:47:31:532 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_20] > 2023-10-23 13:47:31:536 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_24] > 2023-10-23 13:47:31:539 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_16] > 2023-10-23 13:47:31:699 +0300 > [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager] > Failed to process replica request [request=TxFinishReplicaRequestImpl > [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24, > groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0, > 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9, > 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22, > 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24], > term=111283839559532593, timestampLong=111283932466315264, > txId=018b5c25-7653---23c06ab5]] > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367) > at > java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169) > at > java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103) > at > org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456) > at > org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281) >
[jira] [Resolved] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[ https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-20731. --- Resolution: Cannot Reproduce > Exception "The primary replica has changed" on big amount of rows > - > > Key: IGNITE-20731 > URL: https://issues.apache.org/jira/browse/IGNITE-20731 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > *Steps to reproduce:* > 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m" > 2. Execute > {code:java} > create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50) > not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, > column_4 VARCHAR(50) not null, primary key (id)) {code} > 3. Insert rows into table up to 1 000 000 rows. > *Expected result:* > Rows are inserted. > *Actual result:* > After 733000 rows the exception is thrown. > Client: > {code:java} > java.sql.BatchUpdateException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155) > {code} > Server: > {code:java} > 2023-10-23 13:47:31:529 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_12] > 2023-10-23 13:47:31:532 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_20] > 2023-10-23 13:47:31:536 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_24] > 2023-10-23 13:47:31:539 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_16] > 2023-10-23 13:47:31:699 +0300 > [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager] > Failed to process replica request [request=TxFinishReplicaRequestImpl > [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24, > groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0, > 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9, > 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22, > 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24], > term=111283839559532593, timestampLong=111283932466315264, > txId=018b5c25-7653---23c06ab5]] > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367) > at > java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169) > at > java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103) > at > org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456) > at > org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281) > at > java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.jav
[jira] [Closed] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak closed IGNITE-21644. - > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak reopened IGNITE-21644: --- > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-21644. --- Resolution: Invalid > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-21644. --- Resolution: Fixed The problem was that I've use the same Map in two putAllAsync calls. At the time they actually read the map it contains the same keys - the last batch. That’s why we have a deadlock. I’ll close this issue as invalid. Thanks for you time. > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21776) "Create table if not exists" not a thread safe
[ https://issues.apache.org/jira/browse/IGNITE-21776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21776: -- Description: In two parallel clients: 1) Run DDL (using two clients): ``` create table if not exists parallelCreateTable0 (id INTEGER not null, val VARCHAR not null, primary key (id)) ``` 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc Expected result: # One client creates the table, second one - wait table created # Both client can use the table Actual result: # One client creates the table, second one return control immediatly # Second client fails to use the table, the first one works as expected after the table creating finished. was: In two parallel clients: 1) Run DDL (using two clients): ``` create table if not exists parallelCreateTable0 (id INTEGER not null, val VARCHAR not null, primary key (id)) ``` 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc Expected result: # One client creates the table, second one - wait table created # Both client can use the table Actual result: # One client creates the table, second one return control immediatly # Second client fails to use the table, first one works as expected after the table creating finished. > "Create table if not exists" not a thread safe > -- > > Key: IGNITE-21776 > URL: https://issues.apache.org/jira/browse/IGNITE-21776 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: test.java, test.log > > > In two parallel clients: > 1) Run DDL (using two clients): > ``` > create table if not exists parallelCreateTable0 > (id INTEGER not null, > val VARCHAR not null, > primary key (id)) > ``` > 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc > Expected result: > # One client creates the table, second one - wait table created > # Both client can use the table > Actual result: > # One client creates the table, second one return control immediatly > # Second client fails to use the table, the first one works as expected > after the table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21776) "Create table if not exists" not a thread safe
[ https://issues.apache.org/jira/browse/IGNITE-21776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21776: -- Description: In two parallel clients: 1) Run DDL (using two clients): ``` create table if not exists parallelCreateTable0 (id INTEGER not null, val VARCHAR not null, primary key (id)) ``` 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc Expected result: # One client creates the table, second one - wait table created # Both client can use the table Actual result: # One client creates the table, second one return control immediatly # Second client fails to use the table, first one works as expected after the table creating finished. was: In two parallel clients: 1) Run DDL (using two clients): ``` create table if not exists parallelCreateTable0 (id INTEGER not null, val VARCHAR not null, primary key (id)) ``` 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc Expected result: # One client creates the table, second one - wait table created # Both client can use the table Actual result: # One client creates the table, second one return control immediatly # Second client fail to use the table, first one works as expected after the table creating finished. > "Create table if not exists" not a thread safe > -- > > Key: IGNITE-21776 > URL: https://issues.apache.org/jira/browse/IGNITE-21776 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: test.java, test.log > > > In two parallel clients: > 1) Run DDL (using two clients): > ``` > create table if not exists parallelCreateTable0 > (id INTEGER not null, > val VARCHAR not null, > primary key (id)) > ``` > 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc > Expected result: > # One client creates the table, second one - wait table created > # Both client can use the table > Actual result: > # One client creates the table, second one return control immediatly > # Second client fails to use the table, first one works as expected after > the table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21776) "Create table if not exists" not a thread safe
[ https://issues.apache.org/jira/browse/IGNITE-21776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21776: -- Ignite Flags: (was: Docs Required,Release Notes Required) > "Create table if not exists" not a thread safe > -- > > Key: IGNITE-21776 > URL: https://issues.apache.org/jira/browse/IGNITE-21776 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: test.java, test.log > > > In two parallel clients: > 1) Run DDL (using two clients): > ``` > create table if not exists parallelCreateTable0 > (id INTEGER not null, > val VARCHAR not null, > primary key (id)) > ``` > 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc > Expected result: > # One client creates the table, second one - wait table created > # Both client can use the table > Actual result: > # One client creates the table, second one return control immediatly > # Second client fail to use the table, first one works as expected after the > table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21776) "Create table if not exists" not a thread safe
[ https://issues.apache.org/jira/browse/IGNITE-21776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21776: -- Attachment: test.java test.log > "Create table if not exists" not a thread safe > -- > > Key: IGNITE-21776 > URL: https://issues.apache.org/jira/browse/IGNITE-21776 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: test.java, test.log > > > In two parallel clients: > 1) Run DDL (using two clients): > ``` > create table if not exists parallelCreateTable0 > (id INTEGER not null, > val VARCHAR not null, > primary key (id)) > ``` > 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc > Expected result: > # One client creates the table, second one - wait table created > # Both client can use the table > Actual result: > # One client creates the table, second one return control immediatly > # Second client fail to use the table, first one works as expected after the > table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21776) "Create table if not exists" not a thread safe
[ https://issues.apache.org/jira/browse/IGNITE-21776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21776: -- Summary: "Create table if not exists" not a thread safe (was: Create table if not exists not a thread safe) > "Create table if not exists" not a thread safe > -- > > Key: IGNITE-21776 > URL: https://issues.apache.org/jira/browse/IGNITE-21776 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > In two parallel clients: > 1) Run DDL (using two clients): > ``` > create table if not exists parallelCreateTable0 > (id INTEGER not null, > val VARCHAR not null, > primary key (id)) > ``` > 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc > Expected result: > # One client creates the table, second one - wait table created > # Both client can use the table > Actual result: > # One client creates the table, second one return control immediatly > # Second client fail to use the table, first one works as expected after the > table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21776) Create table if not exists not a thread safe
Alexander Belyak created IGNITE-21776: - Summary: Create table if not exists not a thread safe Key: IGNITE-21776 URL: https://issues.apache.org/jira/browse/IGNITE-21776 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak In two parallel clients: 1) Run DDL (using two clients): ``` create table if not exists parallelCreateTable0 (id INTEGER not null, val VARCHAR not null, primary key (id)) ``` 2) Get parallelCreateTable0 using ignite.tables() API or select from jdbc Expected result: # One client creates the table, second one - wait table created # Both client can use the table Actual result: # One client creates the table, second one return control immediatly # Second client fail to use the table, first one works as expected after the table creating finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21644: -- Description: # Create table T1 # Get KeyValue view or Record View # Make a batch of 100 rows and call CompletableFuture f = view.putAllAsync(null , batch) or view. upsertAllAsync(null, batch) # Make another batch and compose it with the first CompletableFuture with: f.thenCompose(r -> view.putAllAsync(null, newBatch)); Expected behavior: batch completed sucessfully. Actual behavior: Failed to acquire a lock due to a possible deadlock was: # Create table T1 # Get KeyValue view or Record View # Make a batch of 100 rows and call CompletableFuture f = view.putAllAsync(null , batch) or view. upsertAllAsync(null, batch) # Make another > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Critical > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21644: -- Summary: Deadlock prevention makes Java Async APIs (KV/RV) hard to use (was: Deadlock prevention makes Java Async APIs (KV/RV) barely usable) > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Critical > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) barely usable
Alexander Belyak created IGNITE-21644: - Summary: Deadlock prevention makes Java Async APIs (KV/RV) barely usable Key: IGNITE-21644 URL: https://issues.apache.org/jira/browse/IGNITE-21644 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 3.0 Reporter: Alexander Belyak # Create table T1 # Get KeyValue view or Record View # Make a batch of 100 rows and call CompletableFuture f = view.putAllAsync(null , batch) or view. upsertAllAsync(null, batch) # Make another -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21537) Connection refused exception contains 800 lines
Alexander Belyak created IGNITE-21537: - Summary: Connection refused exception contains 800 lines Key: IGNITE-21537 URL: https://issues.apache.org/jira/browse/IGNITE-21537 Project: Ignite Issue Type: Improvement Components: clients Affects Versions: 3.0 Reporter: Alexander Belyak Attachments: reconnectException.txt # Start Ignite3 server node, create some table # Start Java client and do some query in the loop # Kill the server node Expected behaviour: * "Connection reset by peer" exception * some reconnect exception(s) Actual behaviour: * "Connection reset by peer" exception * 800 LOC exception with recursion (see the attachment) Client code is: {code:java} try (IgniteClient client = IgniteClient.builder().addresses("172.24.1.2:10800").build()) { while (true) { QAaaSUtils.sleep(1000); System.out.println("Has " + client.connections().size() + " connections"); System.out.println(client.connections()); try (Session sesssion = client.sql().createSession(); ResultSet rs = sesssion.execute(null, "select * from cachepoc_part_a_0 limit 10")) { System.out.println("Query executed"); while (rs.hasNext()) { SqlRow row = rs.next(); System.out.println(row); } } } } {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21228) Data not available thtough JDBC after inserting using KV for a while
Alexander Belyak created IGNITE-21228: - Summary: Data not available thtough JDBC after inserting using KV for a while Key: IGNITE-21228 URL: https://issues.apache.org/jira/browse/IGNITE-21228 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 3.0 Reporter: Alexander Belyak # Create table using java API # Insert 100 rows using sync KV java API # Connect using JDBC and try to select inserted data Expected result: all rows available Actual result: no rows available for a few hundreds of milliseconds (700-1000ms on my laptop). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21039) Network performance optimization
[ https://issues.apache.org/jira/browse/IGNITE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21039: -- Description: I've run several test to find out the MessagingService performance metrics and that is what I've found: {noformat} TestBoolaMessage 139MB/sec WARD TestByteaMessage 132MB/sec WARD TestDoubleaMessage 102MB/sec WARD TestFloataMessage 132MB/sec WARD TestDoubleaMessage 130MB/sec WARD TestLongaMessage 131MB/sec WARD TestDoubleaMessage 131MB/sec WARD TestStringaMessage 280MB/sec WARD TestBoolMessage 11MB/sec WARD WARD TestByteMessage 12MB/sec WARD TestDoubleMessage 12MB/sec WARD TestFloatMessage 13MB/sec WARD TestIntMessage 12MB/sec WARD TestLongMessage 11MB/sec WARD TestShortMessage 12MB/sec WARD TestStringMessage 18MB/sec WARD TestBool20Message 15MB/sec WARD TestByte20Message 12MB/sec WARD TestDouble20Message 32MB/sec WARD TestFloat20Message 22MB/sec WARD TestInt20Message 13MB/sec WARD TestLong20Message 14MB/sec WARD TestShort20Message 14MB/sec WARD TestString20Message 65MB/sec WARD {noformat} All messages were sent in the same setup: 2 server nodes, connected with a *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel 2 --json --version4) shows about *850MB/sec* network throughput. But the *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of messages: 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except String) of type . 2. {*}TestMessage{*}: single property (primitive, except String) of type 3. {*}Test20Message{*}: 20 property (primitive, except String) of type All the messages were sent in parallel from the single thread with the window of 100 messages (right after getting another first ack - the new message were sent). It was expected, that network utilization low for the very short messages (like 1 int or 20 int fields), but in comparison with the iperf3 results, the performance of MessagingService for 163KBytes messages was very low. It became significantly better only while sending huge array of strings (same string "{color:#067d17}Test string to check message service performance.{color}"). I've run another butch of tests with 1KB byte[] property in the message in 1 and 8 threads and without send window at all (each thread sends next message after getting the ack for the previous one): * *1 thread* and got *37 MBytes/sec* * *8 threads* and got *63 MBytes/sec* result. So I suppose there is pretty much contention. All messages were sent in the followin manner: {code:java} private void send(ClusterNode target, NetworkMessage msg) { messagingService.send(target, msg).handle((v, t) -> { if (t != null) { LOG.info("Error while sending huge message", t); } if (time() < timeout) { send(target, msg); } }{code} * was: I've run several test to find out the MessagingService performance metrics and that is what I've found: {noformat} TestBoolaMessage 139MB/sec WARD TestByteaMessage 132MB/sec WARD TestDoubleaMessage 102MB/sec WARD TestFloataMessage 132MB/sec WARD TestDoubleaMessage 130MB/sec WARD TestLongaMessage 131MB/sec WARD TestDoubleaMessage 131MB/sec WARD TestStringaMessage 280MB/sec WARD TestBoolMessage 11MB/sec WARD WARD TestByteMessage 12MB/sec WARD TestDoubleMessage 12MB/sec WARD TestFloatMessage 13MB/sec WARD TestIntMessage 12MB/sec WARD TestLongMessage 11MB/sec WARD TestShortMessage 12MB/sec WARD TestStringMessage 18MB/sec WARD TestBool20Message 15MB/sec WARD TestByte20Message 12MB/sec WARD TestDouble20Message 32MB/sec WARD TestFloat20Message 22MB/sec WARD TestInt20Message 13MB/sec WARD TestLong20Message 14MB/sec WARD TestShort20Message 14MB/sec WARD TestString20Message 65MB/sec WARD {noformat} All messages were sent in the same setup: 2 server nodes, connected with a *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel 2 --json --version4) shows about *850MB/sec* network throughput. But the *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of messages: 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except String) of type . 2. {*}TestMessage{*}: single property (primitive, except String) of type 3. {*}Test20Message{*}: 20 property (primitive, except String) of type All the messages were sent in parallel from the single thread with the window of 100 messages (right after getting another first ack - the new message were sent). It was expected, that network utilization low for the very short messages (like 1 int or 20 int fields), but in comparison with the iperf3 results, the performance of MessagingService for 163KBytes messages was very low. It became significantly better only while sending huge array of strings (same string "{color:#067d17}Test string to chec
[jira] [Updated] (IGNITE-21039) Network performance optimization
[ https://issues.apache.org/jira/browse/IGNITE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-21039: -- Description: I've run several test to find out the MessagingService performance metrics and that is what I've found: {noformat} TestBoolaMessage 139MB/sec WARD TestByteaMessage 132MB/sec WARD TestDoubleaMessage 102MB/sec WARD TestFloataMessage 132MB/sec WARD TestDoubleaMessage 130MB/sec WARD TestLongaMessage 131MB/sec WARD TestDoubleaMessage 131MB/sec WARD TestStringaMessage 280MB/sec WARD TestBoolMessage 11MB/sec WARD WARD TestByteMessage 12MB/sec WARD TestDoubleMessage 12MB/sec WARD TestFloatMessage 13MB/sec WARD TestIntMessage 12MB/sec WARD TestLongMessage 11MB/sec WARD TestShortMessage 12MB/sec WARD TestStringMessage 18MB/sec WARD TestBool20Message 15MB/sec WARD TestByte20Message 12MB/sec WARD TestDouble20Message 32MB/sec WARD TestFloat20Message 22MB/sec WARD TestInt20Message 13MB/sec WARD TestLong20Message 14MB/sec WARD TestShort20Message 14MB/sec WARD TestString20Message 65MB/sec WARD {noformat} All messages were sent in the same setup: 2 server nodes, connected with a *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel 2 --json --version4) shows about *850MB/sec* network throughput. But the *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of messages: 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except String) of type . 2. {*}TestMessage{*}: single property (primitive, except String) of type 3. {*}Test20Message{*}: 20 property (primitive, except String) of type All the messages were sent in parallel from the single thread with the window of 100 messages (right after getting another first ack - the new message were sent). It was expected, that network utilization low for the very short messages (like 1 int or 20 int fields), but in comparison with the iperf3 results, the performance of MessagingService for 163KBytes messages was very low. It became significantly better only while sending huge array of strings (same string "{color:#067d17}Test string to check message service performance.{color}"). I've run another butch of tests with 1KB byte[] property in the message in 1 and 8 threads and without send window at all (each thread sends next message after getting the ack for the previous one): * *1 thread* and got *37 MBytes/sec* * *8 threads* and got *63 MBytes/sec* result. So I suppose there is pretty much contention. All messages were sent in the followin manner: {code:java} private void send(ClusterNode target, NetworkMessage msg) { messagingService.send(target, msg).handle((v, t) -> { if (t != null) { LOG.info("Error while sending huge message", t); } if (time() < timeout) { send(target, msg); } }{code} * was: I've run several test to find out the MessagingService performance metrics and that is what I've found: {noformat} TestBoolaMessage 139MB/sec WARD TestByteaMessage 132MB/sec WARD TestDoubleaMessage 102MB/sec WARD TestFloataMessage 132MB/sec WARD TestDoubleaMessage 130MB/sec WARD TestLongaMessage 131MB/sec WARD TestDoubleaMessage 131MB/sec WARD TestStringaMessage 280MB/sec WARD TestBoolMessage 11MB/sec WARD WARD TestByteMessage 12MB/sec WARD TestDoubleMessage 12MB/sec WARD TestFloatMessage 13MB/sec WARD TestIntMessage 12MB/sec WARD TestLongMessage 11MB/sec WARD TestShortMessage 12MB/sec WARD TestStringMessage 18MB/sec WARD TestBool20Message 15MB/sec WARD TestByte20Message 12MB/sec WARD TestDouble20Message 32MB/sec WARD TestFloat20Message 22MB/sec WARD TestInt20Message 13MB/sec WARD TestLong20Message 14MB/sec WARD TestShort20Message 14MB/sec WARD TestString20Message 65MB/sec WARD {noformat} All messages were sent in the same setup: 2 server nodes, connected with a *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel 2 --json --version4) shows about *850MB/sec* network throughput. But the *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of messages: 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except String) of type . 2. {*}TestMessage{*}: single property (primitive, except String) of type 3. {*}Test20Message{*}: 20 property (primitive, except String) of type All the messages were sent in parallel from the single thread with the window of 100 messages (right after getting another first ack - the new message were sent). It was expected, that network utilization low for the very short messages (like 1 int or 20 int fields), but in comparison with the iperf3 results, the performance of MessagingService for 163KBytes messages was very low. It became significantly better only while sending huge array of strings (same string "{color:#067d17}Test string to chec
[jira] [Created] (IGNITE-21039) Network performance optimization
Alexander Belyak created IGNITE-21039: - Summary: Network performance optimization Key: IGNITE-21039 URL: https://issues.apache.org/jira/browse/IGNITE-21039 Project: Ignite Issue Type: Improvement Components: networking Affects Versions: 3.0 Reporter: Alexander Belyak I've run several test to find out the MessagingService performance metrics and that is what I've found: {noformat} TestBoolaMessage 139MB/sec WARD TestByteaMessage 132MB/sec WARD TestDoubleaMessage 102MB/sec WARD TestFloataMessage 132MB/sec WARD TestDoubleaMessage 130MB/sec WARD TestLongaMessage 131MB/sec WARD TestDoubleaMessage 131MB/sec WARD TestStringaMessage 280MB/sec WARD TestBoolMessage 11MB/sec WARD WARD TestByteMessage 12MB/sec WARD TestDoubleMessage 12MB/sec WARD TestFloatMessage 13MB/sec WARD TestIntMessage 12MB/sec WARD TestLongMessage 11MB/sec WARD TestShortMessage 12MB/sec WARD TestStringMessage 18MB/sec WARD TestBool20Message 15MB/sec WARD TestByte20Message 12MB/sec WARD TestDouble20Message 32MB/sec WARD TestFloat20Message 22MB/sec WARD TestInt20Message 13MB/sec WARD TestLong20Message 14MB/sec WARD TestShort20Message 14MB/sec WARD TestString20Message 65MB/sec WARD {noformat} All messages were sent in the same setup: 2 server nodes, connected with a *10GBit* interface. *Iperf3* (iperf3 --time 30 --zerocopy --client 192.168.1.126 --omit 3 --interval 1 --length 16384 --window 131072 --parallel 2 --json --version4) shows about *850MB/sec* network throughput. But the *best AI3* result was only {*}280MB/sec{*}. Upper results use 3 type of messages: 1. {*}TestaMessage{*}: array of 163840 elements (primitive, except String) of type . 2. {*}TestMessage{*}: single property (primitive, except String) of type 3. {*}Test20Message{*}: 20 property (primitive, except String) of type All the messages were sent in parallel from the single thread with the window of 100 messages (right after getting another first ack - the new message were sent). It was expected, that network utilization low for the very short messages (like 1 int or 20 int fields), but in comparison with the iperf3 results, the performance of MessagingService for 163KBytes messages was very low. It became significantly better only while sending huge array of strings (same string "{color:#067d17}Test string to check message service performance.{color}"). I've run another butch of tests with 1KB byte[] property in the message in 1 and 8 threads and without send window at all (each thread sends next message after getting the ack for the previous one): ** 1 thread* and got *37 MBytes/sec* *** *8 threads* and got *63 MBytes/sec* result. So I suppose there is pretty much contention. All messages were sent in the followin manner: {code:java} private void send(ClusterNode target, NetworkMessage msg) { messagingService.send(target, msg).handle((v, t) -> { if (t != null) { LOG.info("Error while sending huge message", t); } if (time() < timeout) { send(target, msg); } }{code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20765) Error while trimming update log: B+Tree is corrupted
[ https://issues.apache.org/jira/browse/IGNITE-20765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20765: -- Labels: ignite-3 (was: ) > Error while trimming update log: B+Tree is corrupted > > > Key: IGNITE-20765 > URL: https://issues.apache.org/jira/browse/IGNITE-20765 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Create table with 6 col (int key, 5 varchars), insert 1M rows in each via > Batch JDBC insert. > Expected result: insert 1M rows successfully > Actual result: > {noformat} > 2023-10-31 04:07:52:526 + > [INFO][%TablesAmountCapacityTest_cluster_0%checkpoint-thread-2][Checkpointer] > Checkpoint finished [checkpointId=36019ae3-7138-4db3-8b5f-def956ddfb20, > pages=8432, pagesWriteTime=151ms, fsyncTime=276ms, totalTime=437ms] > 2023-10-31 04:08:23:607 + > [INFO][%TablesAmountCapacityTest_cluster_0%vault-2][LowWatermark] Successful > low watermark update: HybridTimestamp [time=111327484549464071, > physical=1698722603599, logical=7] > 2023-10-31 04:08:23:631 + > [WARNING][%TablesAmountCapacityTest_cluster_0%sql-execution-pool-3][ReplicaManager] > Failed to process replica request > [request=ReadWriteMultiRowReplicaRequestImpl [binaryTuples=ArrayList > [java.nio.HeapByteBuffer[pos=0 lim=210 cap=210]], > commitPartitionId=TablePartitionIdMessageImpl [partitionId=9, tableId=5], > full=false, groupId=5_part_17, requestType=RW_INSERT_ALL, schemaVersion=1, > skipDelayedAck=true, term=111327465343483945, > timestampLong=111327661497188477, > transactionId=018b83eb-1537-0062--23c06ab5]] > java.util.concurrent.CompletionException: > org.apache.ignite.internal.storage.StorageException: IGN-STORAGE-1 > TraceId:7115c23f-732f-43ff-b0be-dbf6257fe04e Error while trimming update log: > B+Tree is corrupted [groupId=5, pageIds=[563022967865354], groupName=5, > msg=Runtime failure on search row: > org.apache.ignite.internal.storage.pagememory.mv.UpdateLogKey@184ef004] > at > java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1194) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processMultiEntryAction$111(PartitionReplicaListener.java:2118) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processMultiEntryAction(PartitionReplicaListener.java:2076) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processOperationRequest$20(PartitionReplicaListener.java:576) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1810) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:576) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$16(PartitionReplicaListener.java:506) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:506) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$invoke$12(PartitionReplicaListener.java:481) > at > java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) > at > java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) > at > org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.invoke(PartitionReplicaListener.java:481) > at > org.apache.ignite.internal.replicator.Replica.processRequest(Replica.java:140) > at > org.apache.ignite.internal.replicator.ReplicaManager.onReplicaMessageReceived(ReplicaManager.java:287) > at > org.apache.ignite.network.DefaultMessagingService.sendToSelf(DefaultMessagingService.java:337) > at > org.apache.ignite.network.DefaultMessagingSe
[jira] [Created] (IGNITE-20765) Error while trimming update log: B+Tree is corrupted
Alexander Belyak created IGNITE-20765: - Summary: Error while trimming update log: B+Tree is corrupted Key: IGNITE-20765 URL: https://issues.apache.org/jira/browse/IGNITE-20765 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 3.0 Reporter: Alexander Belyak Create table with 6 col (int key, 5 varchars), insert 1M rows in each via Batch JDBC insert. Expected result: insert 1M rows successfully Actual result: {noformat} 2023-10-31 04:07:52:526 + [INFO][%TablesAmountCapacityTest_cluster_0%checkpoint-thread-2][Checkpointer] Checkpoint finished [checkpointId=36019ae3-7138-4db3-8b5f-def956ddfb20, pages=8432, pagesWriteTime=151ms, fsyncTime=276ms, totalTime=437ms] 2023-10-31 04:08:23:607 + [INFO][%TablesAmountCapacityTest_cluster_0%vault-2][LowWatermark] Successful low watermark update: HybridTimestamp [time=111327484549464071, physical=1698722603599, logical=7] 2023-10-31 04:08:23:631 + [WARNING][%TablesAmountCapacityTest_cluster_0%sql-execution-pool-3][ReplicaManager] Failed to process replica request [request=ReadWriteMultiRowReplicaRequestImpl [binaryTuples=ArrayList [java.nio.HeapByteBuffer[pos=0 lim=210 cap=210]], commitPartitionId=TablePartitionIdMessageImpl [partitionId=9, tableId=5], full=false, groupId=5_part_17, requestType=RW_INSERT_ALL, schemaVersion=1, skipDelayedAck=true, term=111327465343483945, timestampLong=111327661497188477, transactionId=018b83eb-1537-0062--23c06ab5]] java.util.concurrent.CompletionException: org.apache.ignite.internal.storage.StorageException: IGN-STORAGE-1 TraceId:7115c23f-732f-43ff-b0be-dbf6257fe04e Error while trimming update log: B+Tree is corrupted [groupId=5, pageIds=[563022967865354], groupName=5, msg=Runtime failure on search row: org.apache.ignite.internal.storage.pagememory.mv.UpdateLogKey@184ef004] at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1194) at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processMultiEntryAction$111(PartitionReplicaListener.java:2118) at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processMultiEntryAction(PartitionReplicaListener.java:2076) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processOperationRequest$20(PartitionReplicaListener.java:576) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1810) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:576) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$16(PartitionReplicaListener.java:506) at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:506) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$invoke$12(PartitionReplicaListener.java:481) at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187) at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309) at org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.invoke(PartitionReplicaListener.java:481) at org.apache.ignite.internal.replicator.Replica.processRequest(Replica.java:140) at org.apache.ignite.internal.replicator.ReplicaManager.onReplicaMessageReceived(ReplicaManager.java:287) at org.apache.ignite.network.DefaultMessagingService.sendToSelf(DefaultMessagingService.java:337) at org.apache.ignite.network.DefaultMessagingService.invoke0(DefaultMessagingService.java:262) at org.apache.ignite.network.DefaultMessagingService.invoke(DefaultMessagingService.java:190) at org.apache.ignite.network.MessagingService.invoke(MessagingService.java:194) at org.apache.ignite.internal.replicator.ReplicaService.sendToReplica(ReplicaService.java:92) at org.apache
[jira] [Created] (IGNITE-20762) Unable to create table in a specific zone
Alexander Belyak created IGNITE-20762: - Summary: Unable to create table in a specific zone Key: IGNITE-20762 URL: https://issues.apache.org/jira/browse/IGNITE-20762 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Got exception [Code: 0, SQL State: 5] Failed to validate query. Distribution zone with name 'fz' not found on creation a new table in any specific zone: {noformat} create zone fz engine aipersist; >> success create table testt3 (id integer not null, val varchar not null, id2 integer not null, primary key(id,id2) ) with primary_zone = 'fz'; >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone >> with name 'fz' not found create zone fz engine aipersist; >> [Code: 0, SQL State: 5] Distribution zone already exists [zoneName=FZ] drop zone fz; >> success{noformat} Code from the example: [https://github.com/apache/ignite-3/blob/main/examples/src/main/java/org/apache/ignite/example/storage/StorageEngineExample.java] no matter if the first statement will use any region: {noformat} create zone fz2 engine aipersist with dataregion = 'asd'; >> success create table testt3 (id integer not null, val varchar not null, id2 integer not null, primary key(id,id2) ) with primary_zone = 'fz2'; >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone >> with name 'fz2' not found{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[ https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781013#comment-17781013 ] Alexander Belyak edited comment on IGNITE-20731 at 10/30/23 1:24 PM: - Same error on test: create 1000 empty table with 5 column, insert 1 row, execute 1 simple query on each. GC pauses up to 24sec. was (Author: berkov): Same error on test: create 1000 empty table with 5 column, insert 1 row, execute 1 simple query on each. > Exception "The primary replica has changed" on big amount of rows > - > > Key: IGNITE-20731 > URL: https://issues.apache.org/jira/browse/IGNITE-20731 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > *Steps to reproduce:* > 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m" > 2. Execute > {code:java} > create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50) > not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, > column_4 VARCHAR(50) not null, primary key (id)) {code} > 3. Insert rows into table up to 1 000 000 rows. > *Expected result:* > Rows are inserted. > *Actual result:* > After 733000 rows the exception is thrown. > Client: > {code:java} > java.sql.BatchUpdateException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155) > {code} > Server: > {code:java} > 2023-10-23 13:47:31:529 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_12] > 2023-10-23 13:47:31:532 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_20] > 2023-10-23 13:47:31:536 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_24] > 2023-10-23 13:47:31:539 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_16] > 2023-10-23 13:47:31:699 +0300 > [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager] > Failed to process replica request [request=TxFinishReplicaRequestImpl > [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24, > groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0, > 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9, > 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22, > 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24], > term=111283839559532593, timestampLong=111283932466315264, > txId=018b5c25-7653---23c06ab5]] > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367) > at > java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169) > at > java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103) > at > org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849) > at > org.apache.i
[jira] [Commented] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[ https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781013#comment-17781013 ] Alexander Belyak commented on IGNITE-20731: --- Same error on test: create 1000 empty table with 5 column, insert 1 row, execute 1 simple query on each. > Exception "The primary replica has changed" on big amount of rows > - > > Key: IGNITE-20731 > URL: https://issues.apache.org/jira/browse/IGNITE-20731 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > *Steps to reproduce:* > 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m" > 2. Execute > {code:java} > create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50) > not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, > column_4 VARCHAR(50) not null, primary key (id)) {code} > 3. Insert rows into table up to 1 000 000 rows. > *Expected result:* > Rows are inserted. > *Actual result:* > After 733000 rows the exception is thrown. > Client: > {code:java} > java.sql.BatchUpdateException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155) > {code} > Server: > {code:java} > 2023-10-23 13:47:31:529 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_12] > 2023-10-23 13:47:31:532 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_20] > 2023-10-23 13:47:31:536 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_24] > 2023-10-23 13:47:31:539 +0300 > [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener] > Primary replica expired [grp=5_part_16] > 2023-10-23 13:47:31:699 +0300 > [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager] > Failed to process replica request [request=TxFinishReplicaRequestImpl > [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24, > groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0, > 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9, > 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22, > 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24], > term=111283839559532593, timestampLong=111283932466315264, > txId=018b5c25-7653---23c06ab5]] > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica > has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0, > currentLeaseholder=null] > at > java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367) > at > java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376) > at > java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169) > at > java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169) > at > org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103) > at > org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849) > at > org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456) > at > org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTi
[jira] [Updated] (IGNITE-20760) Drop column error message get indexes by column name only
[ https://issues.apache.org/jira/browse/IGNITE-20760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20760: -- Labels: ignite-3 (was: ) > Drop column error message get indexes by column name only > -- > > Key: IGNITE-20760 > URL: https://issues.apache.org/jira/browse/IGNITE-20760 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > If there are some index, preventing column to be dropped, then error message > contains all indexes with all columns with the same name. Even if there is > completely different tables with the same named columns: > {code:java} > drop table tab1; > drop table tab2; > create table tab1(id integer not null primary key, f1 int); > create index tab1_f1 on tab1(f1); > create table tab2(id integer not null primary key, f1 int, f2 int); > create index tab2_f1 on tab2(f1); > create index tab2_f12 on tab2(f1,f2); > alter table tab2 drop column f1; > >> Fail with wrong error message: > >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column > >> 'F1' used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed > >> Because it contains TAB1_F1 index > drop index tab2_f12; > drop index tab2_f1; > alter table tab2 drop column f1 > >> Success, so the problem only on the error message generation. {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20760) Drop column error message get indexes by column name only
[ https://issues.apache.org/jira/browse/IGNITE-20760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20760: -- Description: If there are some index, preventing column to be dropped, then error message contains all indexes with all columns with the same name. Even if there is completely different tables with the same named columns: {code:java} drop table tab1; drop table tab2; create table tab1(id integer not null primary key, f1 int); create index tab1_f1 on tab1(f1); create table tab2(id integer not null primary key, f1 int, f2 int); create index tab2_f1 on tab2(f1); create index tab2_f12 on tab2(f1,f2); alter table tab2 drop column f1; >> Fail with wrong error message: >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column 'F1' >> used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed >> Because it contains TAB1_F1 index drop index tab2_f12; drop index tab2_f1; alter table tab2 drop column f1 >> Success, so the problem only on the error message generation. {code} was: If there are some index, preventing column to be dropped, then error message contains all indexes with all columns with the same name. Even if there is completely different tables with the same named columns: {code:java} drop table tab1; drop table tab2; create table tab1(id integer not null primary key, f1 int); create index tab1_f1 on tab1(f1); create table tab2(id integer not null primary key, f1 int, f2 int); create index tab2_f1 on tab2(f1); create index tab2_f12 on tab2(f1,f2); alter table tab2 drop column f1; >> Fail with wrong error message: >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column 'F1' >> used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed >> Because it contains TAB1_F1 index drop index tab2_f12; drop index tab2_f1; alter table tab2 drop column f1 >> Success, so the problem only on the error message generation. {code} > Drop column error message get indexes by column name only > -- > > Key: IGNITE-20760 > URL: https://issues.apache.org/jira/browse/IGNITE-20760 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > If there are some index, preventing column to be dropped, then error message > contains all indexes with all columns with the same name. Even if there is > completely different tables with the same named columns: > {code:java} > drop table tab1; > drop table tab2; > create table tab1(id integer not null primary key, f1 int); > create index tab1_f1 on tab1(f1); > create table tab2(id integer not null primary key, f1 int, f2 int); > create index tab2_f1 on tab2(f1); > create index tab2_f12 on tab2(f1,f2); > alter table tab2 drop column f1; > >> Fail with wrong error message: > >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column > >> 'F1' used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed > >> Because it contains TAB1_F1 index > drop index tab2_f12; > drop index tab2_f1; > alter table tab2 drop column f1 > >> Success, so the problem only on the error message generation. {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20760) Drop column error message get indexes by column name only
[ https://issues.apache.org/jira/browse/IGNITE-20760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20760: -- Description: If there are some index, preventing column to be dropped, then error message contains all indexes with all columns with the same name. Even if there is completely different tables with the same named columns: {code:java} drop table tab1; drop table tab2; create table tab1(id integer not null primary key, f1 int); create index tab1_f1 on tab1(f1); create table tab2(id integer not null primary key, f1 int, f2 int); create index tab2_f1 on tab2(f1); create index tab2_f12 on tab2(f1,f2); alter table tab2 drop column f1; >> Fail with wrong error message: >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column 'F1' >> used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed >> Because it contains TAB1_F1 index drop index tab2_f12; drop index tab2_f1; alter table tab2 drop column f1 >> Success, so the problem only on the error message generation. {code} was: If there are some index, preventing column to be dropped, then error message contains all indexes with all columns with the same name. Even if there is completely different tables with the same named columns: {code:java} drop table tab1; drop table tab2; create table tab1(id integer not null primary key, f1 int); create index tab1_f1 on tab1(f1);create table tab2(id integer not null primary key, f1 int, f2 int); create index tab2_f1 on tab2(f1); create index tab2_f12 on tab2(f1,f2);alter table tab2 drop column f1 >> Fail with wrong error message: >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column 'F1' >> used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed >> Because it contains TAB1_F1 indexdrop index tab2_f12; drop index tab2_f1;alter table tab2 drop column f1 >> Success, so the problem only on the error message generation. {code} > Drop column error message get indexes by column name only > -- > > Key: IGNITE-20760 > URL: https://issues.apache.org/jira/browse/IGNITE-20760 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > If there are some index, preventing column to be dropped, then error message > contains all indexes with all columns with the same name. Even if there is > completely different tables with the same named columns: > {code:java} > drop table tab1; > drop table tab2; > create table tab1(id integer not null primary key, f1 int); > create index tab1_f1 on tab1(f1); > create table tab2(id integer not null primary key, f1 int, f2 int); > create index tab2_f1 on tab2(f1); > create index tab2_f12 on tab2(f1,f2); > alter table tab2 drop column f1; > >> Fail with wrong error message: > >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column > >> 'F1' used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed > >> Because it contains TAB1_F1 index > drop index tab2_f12; > drop index tab2_f1; > alter table tab2 drop column f1 > >> Success, so the problem only on the error message generation. {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20760) Drop column error message get indexes by column name only
Alexander Belyak created IGNITE-20760: - Summary: Drop column error message get indexes by column name only Key: IGNITE-20760 URL: https://issues.apache.org/jira/browse/IGNITE-20760 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak If there are some index, preventing column to be dropped, then error message contains all indexes with all columns with the same name. Even if there is completely different tables with the same named columns: {code:java} drop table tab1; drop table tab2; create table tab1(id integer not null primary key, f1 int); create index tab1_f1 on tab1(f1);create table tab2(id integer not null primary key, f1 int, f2 int); create index tab2_f1 on tab2(f1); create index tab2_f12 on tab2(f1,f2);alter table tab2 drop column f1 >> Fail with wrong error message: >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column 'F1' >> used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed >> Because it contains TAB1_F1 indexdrop index tab2_f12; drop index tab2_f1;alter table tab2 drop column f1 >> Success, so the problem only on the error message generation. {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20747) Broken "Edit" link on a doc pages
Alexander Belyak created IGNITE-20747: - Summary: Broken "Edit" link on a doc pages Key: IGNITE-20747 URL: https://issues.apache.org/jira/browse/IGNITE-20747 Project: Ignite Issue Type: Bug Components: documentation, website Affects Versions: 3.0 Reporter: Alexander Belyak On its documentation page Ignite has an "Edit" link: * [https://ignite.apache.org/docs/3.0.0-beta/config/data-region] * [https://ignite.apache.org/docs/3.0.0-beta/compute/compute] like [https://github.com/apache/ignite/tree/IGNITE-7595/docs/_docs/binary-protocol.adoc] I have no idea why this link exists, but for now they all broken (return 404) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20683) "Failed to stop replica" caused by node is stopping
[ https://issues.apache.org/jira/browse/IGNITE-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20683: -- Attachment: ItSqlExamplesTest.java > "Failed to stop replica" caused by node is stopping > --- > > Key: IGNITE-20683 > URL: https://issues.apache.org/jira/browse/IGNITE-20683 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Critical > Attachments: IGNITE-20683.txt, ItSqlExamplesTest.java > > > Basic test case: > 1) start node > 2) create table (key int, val varchar) > 3) insert 10k rows by 100 rows batches > 4) call node.close() > Expected result: node stopped without errors > Actual result: node logs full of exceptions (see attachment) like: > {noformat} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.lang.NodeStoppingException: IGN-CMN-1 > TraceId:3d122dd6-0a37-431e-a8ce-89f9a39bca90 Operation has been cancelled > (node is stopping). > at > java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) > ~[?:?] > at > java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423) > ~[?:?] > at > java.util.concurrent.CompletableFuture$CoCompletion.tryFire(CompletableFuture.java:1144) > ~[?:?] > at > java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) > ~[?:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.lambda$sendWithRetry$2(TopologyAwareRaftGroupService.java:237) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) > [?:?] > at > java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) > [?:?] > at > java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) > [?:?] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > Caused by: org.apache.ignite.internal.lang.NodeStoppingException: Operation > has been cancelled (node is stopping). > at > org.apache.ignite.network.DefaultMessagingService.invoke0(DefaultMessagingService.java:244) > ~[ignite-network-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.network.DefaultMessagingService.invoke(DefaultMessagingService.java:176) > ~[ignite-network-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.network.MessagingService.invoke(MessagingService.java:167) > ~[ignite-network-api-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendWithRetry(TopologyAwareRaftGroupService.java:211) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendSubscribeMessage(TopologyAwareRaftGroupService.java:197) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.unsubscribeLeader(TopologyAwareRaftGroupService.java:329) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.replicator.Replica.shutdown(Replica.java:294) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) > ~[?:?] > at > java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) > ~[?:?] > at > org.apache.ignite.internal.replicator.ReplicaManager.stopReplicaInternal(ReplicaManager.java:520) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.replicator.ReplicaManager.stopReplica(ReplicaManager.java:495) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.table.distributed.TableManager.lambda$cleanUpTablesResources$42(TableManager.java:1109) > ~[ignite-table-3.0.0-SNAPSHOT.jar:?] > at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?] > at > org.apache.ignite.internal.table.distributed.TableManager.cleanUpTablesResources(TableManager.java:1135) >
[jira] [Updated] (IGNITE-20683) "Failed to stop replica" caused by node is stopping
[ https://issues.apache.org/jira/browse/IGNITE-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20683: -- Attachment: IGNITE-20683.txt > "Failed to stop replica" caused by node is stopping > --- > > Key: IGNITE-20683 > URL: https://issues.apache.org/jira/browse/IGNITE-20683 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Critical > Attachments: IGNITE-20683.txt, ItSqlExamplesTest.java > > > Basic test case: > 1) start node > 2) create table (key int, val varchar) > 3) insert 10k rows by 100 rows batches > 4) call node.close() > Expected result: node stopped without errors > Actual result: node logs full of exceptions (see attachment) like: > {noformat} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.lang.NodeStoppingException: IGN-CMN-1 > TraceId:3d122dd6-0a37-431e-a8ce-89f9a39bca90 Operation has been cancelled > (node is stopping). > at > java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) > ~[?:?] > at > java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423) > ~[?:?] > at > java.util.concurrent.CompletableFuture$CoCompletion.tryFire(CompletableFuture.java:1144) > ~[?:?] > at > java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) > ~[?:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.lambda$sendWithRetry$2(TopologyAwareRaftGroupService.java:237) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) > [?:?] > at > java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) > [?:?] > at > java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) > [?:?] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > Caused by: org.apache.ignite.internal.lang.NodeStoppingException: Operation > has been cancelled (node is stopping). > at > org.apache.ignite.network.DefaultMessagingService.invoke0(DefaultMessagingService.java:244) > ~[ignite-network-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.network.DefaultMessagingService.invoke(DefaultMessagingService.java:176) > ~[ignite-network-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.network.MessagingService.invoke(MessagingService.java:167) > ~[ignite-network-api-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendWithRetry(TopologyAwareRaftGroupService.java:211) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendSubscribeMessage(TopologyAwareRaftGroupService.java:197) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.unsubscribeLeader(TopologyAwareRaftGroupService.java:329) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.replicator.Replica.shutdown(Replica.java:294) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) > ~[?:?] > at > java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) > ~[?:?] > at > org.apache.ignite.internal.replicator.ReplicaManager.stopReplicaInternal(ReplicaManager.java:520) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.replicator.ReplicaManager.stopReplica(ReplicaManager.java:495) > ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] > at > org.apache.ignite.internal.table.distributed.TableManager.lambda$cleanUpTablesResources$42(TableManager.java:1109) > ~[ignite-table-3.0.0-SNAPSHOT.jar:?] > at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?] > at > org.apache.ignite.internal.table.distributed.TableManager.cleanUpTablesResources(TableManager.java:1135) > ~[igni
[jira] [Created] (IGNITE-20683) "Failed to stop replica" caused by node is stopping
Alexander Belyak created IGNITE-20683: - Summary: "Failed to stop replica" caused by node is stopping Key: IGNITE-20683 URL: https://issues.apache.org/jira/browse/IGNITE-20683 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 3.0 Reporter: Alexander Belyak Basic test case: 1) start node 2) create table (key int, val varchar) 3) insert 10k rows by 100 rows batches 4) call node.close() Expected result: node stopped without errors Actual result: node logs full of exceptions (see attachment) like: {noformat} java.util.concurrent.CompletionException: org.apache.ignite.internal.lang.NodeStoppingException: IGN-CMN-1 TraceId:3d122dd6-0a37-431e-a8ce-89f9a39bca90 Operation has been cancelled (node is stopping). at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) ~[?:?] at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) ~[?:?] at java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423) ~[?:?] at java.util.concurrent.CompletableFuture$CoCompletion.tryFire(CompletableFuture.java:1144) ~[?:?] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) ~[?:?] at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) ~[?:?] at org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.lambda$sendWithRetry$2(TopologyAwareRaftGroupService.java:237) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) [?:?] at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) [?:?] at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) [?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:829) [?:?] Caused by: org.apache.ignite.internal.lang.NodeStoppingException: Operation has been cancelled (node is stopping). at org.apache.ignite.network.DefaultMessagingService.invoke0(DefaultMessagingService.java:244) ~[ignite-network-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.network.DefaultMessagingService.invoke(DefaultMessagingService.java:176) ~[ignite-network-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.network.MessagingService.invoke(MessagingService.java:167) ~[ignite-network-api-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendWithRetry(TopologyAwareRaftGroupService.java:211) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.sendSubscribeMessage(TopologyAwareRaftGroupService.java:197) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.unsubscribeLeader(TopologyAwareRaftGroupService.java:329) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.replicator.Replica.shutdown(Replica.java:294) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) ~[?:?] at java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) ~[?:?] at org.apache.ignite.internal.replicator.ReplicaManager.stopReplicaInternal(ReplicaManager.java:520) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.replicator.ReplicaManager.stopReplica(ReplicaManager.java:495) ~[ignite-replicator-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.table.distributed.TableManager.lambda$cleanUpTablesResources$42(TableManager.java:1109) ~[ignite-table-3.0.0-SNAPSHOT.jar:?] at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?] at org.apache.ignite.internal.table.distributed.TableManager.cleanUpTablesResources(TableManager.java:1135) ~[ignite-table-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.table.distributed.TableManager.stop(TableManager.java:1061) ~[ignite-table-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.app.LifecycleManager.lambda$stopAllComponents$1(LifecycleManager.java:133) ~[ignite-runner-3.0.0-SNAPSHOT.jar:?] at java.util.Iterator.forEachRemaining(Iterator.java:133) ~[?:?] at org.apache.ignite.internal.app.LifecycleManager.stopAllComponents(LifecycleManager.java:131) ~[ignit
[jira] [Updated] (IGNITE-20622) OOMe during TPC-C scale10
[ https://issues.apache.org/jira/browse/IGNITE-20622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20622: -- Description: Got OOMe during loading TPC-C database with scale 10 (benchbase). Just starting benchbase with TPC-C benchmark with scale factor is enough to get stable OOMe exception in 10 min. (was: Got OOMe during loading TPC-C database with scale 10 (benchbase). TBD) > OOMe during TPC-C scale10 > - > > Key: IGNITE-20622 > URL: https://issues.apache.org/jira/browse/IGNITE-20622 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Got OOMe during loading TPC-C database with scale 10 (benchbase). Just > starting benchbase with TPC-C benchmark with scale factor is enough to get > stable OOMe exception in 10 min. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20622) OOMe during TPC-C scale10
Alexander Belyak created IGNITE-20622: - Summary: OOMe during TPC-C scale10 Key: IGNITE-20622 URL: https://issues.apache.org/jira/browse/IGNITE-20622 Project: Ignite Issue Type: Bug Components: networking Affects Versions: 3.0 Reporter: Alexander Belyak Got OOMe during loading TPC-C database with scale 10 (benchbase). TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20542) Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml
[ https://issues.apache.org/jira/browse/IGNITE-20542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20542: -- Description: [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] Correct one seems to be [openapi.yaml|https://github.com/apache/ignite-3/blob/main/modules/rest-api/openapi/openapi.yaml] (was: [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml]) > Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml > -- > > Key: IGNITE-20542 > URL: https://issues.apache.org/jira/browse/IGNITE-20542 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > Labels: ignite-3 > > [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page > contains broken link to the > [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] > Correct one seems to be > [openapi.yaml|https://github.com/apache/ignite-3/blob/main/modules/rest-api/openapi/openapi.yaml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20542) Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml
Alexander Belyak created IGNITE-20542: - Summary: Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml Key: IGNITE-20542 URL: https://issues.apache.org/jira/browse/IGNITE-20542 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Alexander Belyak [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page contains broken link to the [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20483) MessagingService error on load
Alexander Belyak created IGNITE-20483: - Summary: MessagingService error on load Key: IGNITE-20483 URL: https://issues.apache.org/jira/browse/IGNITE-20483 Project: Ignite Issue Type: Bug Components: networking Affects Versions: 3.0 Reporter: Alexander Belyak Basic test like: {code:java} ClusterNode target = node0.clusterNodes().stream().filter(node -> !node.name().equals(firstNodeName)).findAny().orElseThrow(); TestHugeMessage msg = new TestHugeMessage(new byte[100500]); for (int i = 100_000; i < 100_000_000; i++) { if (i % 100_000 == 0) { System.out.println("i=" + i); } ms1.send(target, msg); } {code} leads to critical error: {noformat} [2023-09-25T11:59:57,088][WARN ][imst_cms_0-srv-worker-4][RecoveryServerHandshakeManager] Handshake rejected by client: imst_cms_0:2dcea174-58b5-4a8d-bf58-acaafdd64365 is stale, server should be restarted so that clients can connect [2023-09-25T11:59:57,090][ERROR][imst_cms_0-srv-worker-4][FailureHandler] Critical failure org.apache.ignite.lang.IgniteException: Handshake rejected by client: imst_cms_0:2dcea174-58b5-4a8d-bf58-acaafdd64365 is stale, server should be restarted so that clients can connect at org.apache.ignite.internal.network.recovery.RecoveryServerHandshakeManager.onMessage(RecoveryServerHandshakeManager.java:197) [ignite-network-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.internal.network.netty.HandshakeHandler.channelRead(HandshakeHandler.java:92) [ignite-network-3.0.0-SNAPSHOT.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) [netty-codec-4.1.87.Final.jar:4.1.87.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) [netty-codec-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) [netty-transport-4.1.87.Final.jar:4.1.87.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) [netty-common-4.1.87.Final.jar:4.1.87.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.87.Final.jar:4.1.87.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.87.Final.jar:4.1.87.Final] at java.lang.Thread.run(Thread.java:829) [?:?]{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20048) Wrong null type for null values in DB tools
[ https://issues.apache.org/jira/browse/IGNITE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20048: -- Description: In tools like DB Visualizer, IDEA, DBeaver user will get: * 0 instead of null in integer fields * false instead of null in varchar fields Reproducer: {noformat} DROP TABLE IF EXISTS test; CREATE TABLE test (id int PRIMARY KEY, vali int, vals varchar); INSERT INTO test(id, vali, vals) values(1,1,'1'),(2,NULL,'2'),(3,3,null); SELECT * FROM test{noformat} Expected result: {noformat} ID VALI VALS3 3 3(null) 2 (null) 2 1 11{noformat} Actual results: {noformat} ID VALI VALS3 3 3false 2 02 1 11{noformat} Commit id: f34beaed But actually database store null values, for example, queries like: {noformat} SELECT * FROM test WHERE vali IS null{noformat} will return: {noformat} ID VALI VALS3 2 0 2{noformat} was: In tools like DB Visualizer, IDEA, DBeaver user will get: * 0 instead of null in integer fields * false instead of null in varchar fields Reproducer: {noformat} DROP TABLE IF EXISTS test;CREATE TABLE test (id int PRIMARY KEY, vali int, vals varchar);INSERT INTO test(id, vali, vals) values(1,1,'1'),(2,NULL,'2'),(3,3,null);SELECT * FROM test{noformat} Expected result: {noformat} ID VALI VALS3 3 3(null) 2 (null) 2 1 11{noformat} Actual results: {noformat} ID VALI VALS3 3 3false 2 02 1 11{noformat} Commit id: f34beaed > Wrong null type for null values in DB tools > --- > > Key: IGNITE-20048 > URL: https://issues.apache.org/jira/browse/IGNITE-20048 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > In tools like DB Visualizer, IDEA, DBeaver user will get: > * 0 instead of null in integer fields > * false instead of null in varchar fields > Reproducer: > {noformat} > DROP TABLE IF EXISTS test; > CREATE TABLE test (id int PRIMARY KEY, vali int, vals varchar); > INSERT INTO test(id, vali, vals) values(1,1,'1'),(2,NULL,'2'),(3,3,null); > SELECT * FROM test{noformat} > Expected result: > {noformat} > ID VALI VALS3 > 3 3(null) > 2 (null) 2 > 1 11{noformat} > Actual results: > {noformat} > ID VALI VALS3 > 3 3false > 2 02 > 1 11{noformat} > Commit id: f34beaed > But actually database store null values, for example, queries like: > {noformat} > SELECT * FROM test WHERE vali IS null{noformat} > will return: > {noformat} > ID VALI VALS3 > 2 0 2{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20048) Wrong null type for null values in DB tools
Alexander Belyak created IGNITE-20048: - Summary: Wrong null type for null values in DB tools Key: IGNITE-20048 URL: https://issues.apache.org/jira/browse/IGNITE-20048 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak In tools like DB Visualizer, IDEA, DBeaver user will get: * 0 instead of null in integer fields * false instead of null in varchar fields Reproducer: {noformat} DROP TABLE IF EXISTS test;CREATE TABLE test (id int PRIMARY KEY, vali int, vals varchar);INSERT INTO test(id, vali, vals) values(1,1,'1'),(2,NULL,'2'),(3,3,null);SELECT * FROM test{noformat} Expected result: {noformat} ID VALI VALS3 3 3(null) 2 (null) 2 1 11{noformat} Actual results: {noformat} ID VALI VALS3 3 3false 2 02 1 11{noformat} Commit id: f34beaed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
[ https://issues.apache.org/jira/browse/IGNITE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20035: -- Description: If setMaxRows > count(*) - query fail with IndexOutOfBound exception. Reproducer: {noformat} try (Connection connection = connect(); Statement statement = connection.createStatement()) { JdbcSteps steps = new JdbcSteps(statement); steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name VARCHAR)", "Creating a table with two columns."); steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, 'John')", "Inserting a single record"); statement.setMaxRows(25); ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all the records from the table"); while (res.next()) { log.info("{}, {}", res.getInt(1), res.getString(2)); assertEquals(1, res.getInt(1)); assertEquals("John", res.getString(2)); } }{noformat} Returns: {noformat} Exception while executing query [query=SELECT * FROM Person]. Error message:toIndex = 25 java.sql.SQLException: Exception while executing query [query=SELECT * FROM Person]. Error message:toIndex = 25 at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108) at org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50) at org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursiv
[jira] [Updated] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
[ https://issues.apache.org/jira/browse/IGNITE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20035: -- Component/s: sql > IndexOutOfBoundsException when statement.SetMaxRows is set > -- > > Key: IGNITE-20035 > URL: https://issues.apache.org/jira/browse/IGNITE-20035 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > If setMaxRows > count(*) - query fail with IndexOutOfBound exception. > Reproducer: > > {noformat} > try (Connection connection = connect(); Statement statement = > connection.createStatement()) { > JdbcSteps steps = new JdbcSteps(statement); > steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name > VARCHAR)", "Creating a table with two columns."); > steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, > 'John')", "Inserting a single record"); > statement.setMaxRows(25); > ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all > the records from the table"); > while (res.next()) { > log.info("{}, {}", res.getInt(1), res.getString(2)); > assertEquals(1, res.getInt(1)); > assertEquals("John", res.getString(2)); > } > }{noformat} > Returns: > > > {noformat} > Exception while executing query [query=SELECT * FROM Person]. Error > message:toIndex = 25 > java.sql.SQLException: Exception while executing query [query=SELECT * FROM > Person]. Error message:toIndex = 25 > at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108) > at > org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50) > at > org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > at > org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMet
[jira] [Created] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
Alexander Belyak created IGNITE-20035: - Summary: IndexOutOfBoundsException when statement.SetMaxRows is set Key: IGNITE-20035 URL: https://issues.apache.org/jira/browse/IGNITE-20035 Project: Ignite Issue Type: Bug Reporter: Alexander Belyak If setMaxRows > count(*) - query fail with IndexOutOfBound exception. Reproducer: {noformat} try (Connection connection = connect(); Statement statement = connection.createStatement()) { JdbcSteps steps = new JdbcSteps(statement); steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name VARCHAR)", "Creating a table with two columns."); steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, 'John')", "Inserting a single record"); statement.setMaxRows(25); ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all the records from the table"); while (res.next()) { log.info("{}, {}", res.getInt(1), res.getString(2)); assertEquals(1, res.getInt(1)); assertEquals("John", res.getString(2)); } }{noformat} Returns: {noformat} Exception while executing query [query=SELECT * FROM Person]. Error message:toIndex = 25 java.sql.SQLException: Exception while executing query [query=SELECT * FROM Person]. Error message:toIndex = 25 at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) at org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108) at org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50) at org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDes
[jira] [Updated] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
[ https://issues.apache.org/jira/browse/IGNITE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20035: -- Labels: ignite-3 (was: ) > IndexOutOfBoundsException when statement.SetMaxRows is set > -- > > Key: IGNITE-20035 > URL: https://issues.apache.org/jira/browse/IGNITE-20035 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > If setMaxRows > count(*) - query fail with IndexOutOfBound exception. > Reproducer: > > {noformat} > try (Connection connection = connect(); Statement statement = > connection.createStatement()) { > JdbcSteps steps = new JdbcSteps(statement); > steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name > VARCHAR)", "Creating a table with two columns."); > steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, > 'John')", "Inserting a single record"); > statement.setMaxRows(25); > ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all > the records from the table"); > while (res.next()) { > log.info("{}, {}", res.getInt(1), res.getString(2)); > assertEquals(1, res.getInt(1)); > assertEquals("John", res.getString(2)); > } > }{noformat} > Returns: > > > {noformat} > Exception while executing query [query=SELECT * FROM Person]. Error > message:toIndex = 25 > java.sql.SQLException: Exception while executing query [query=SELECT * FROM > Person]. Error message:toIndex = 25 > at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108) > at > org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50) > at > org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > at > org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTe
[jira] [Updated] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
[ https://issues.apache.org/jira/browse/IGNITE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20035: -- Affects Version/s: 3.0 > IndexOutOfBoundsException when statement.SetMaxRows is set > -- > > Key: IGNITE-20035 > URL: https://issues.apache.org/jira/browse/IGNITE-20035 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > If setMaxRows > count(*) - query fail with IndexOutOfBound exception. > Reproducer: > > {noformat} > try (Connection connection = connect(); Statement statement = > connection.createStatement()) { > JdbcSteps steps = new JdbcSteps(statement); > steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name > VARCHAR)", "Creating a table with two columns."); > steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, > 'John')", "Inserting a single record"); > statement.setMaxRows(25); > ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all > the records from the table"); > while (res.next()) { > log.info("{}, {}", res.getInt(1), res.getString(2)); > assertEquals(1, res.getInt(1)); > assertEquals("John", res.getString(2)); > } > }{noformat} > Returns: > > > {noformat} > Exception while executing query [query=SELECT * FROM Person]. Error > message:toIndex = 25 > java.sql.SQLException: Exception while executing query [query=SELECT * FROM > Person]. Error message:toIndex = 25 > at > org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) > at > org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) > at > org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108) > at > org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50) > at > org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > at > org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > at > org.junit.jupiter.engine.descriptor.TestMethodTe
[jira] [Updated] (IGNITE-20030) Delete from table with composite PK failed
[ https://issues.apache.org/jira/browse/IGNITE-20030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20030: -- Attachment: IGNITE-20030.zip > Delete from table with composite PK failed > -- > > Key: IGNITE-20030 > URL: https://issues.apache.org/jira/browse/IGNITE-20030 > Project: Ignite > Issue Type: Task >Reporter: Alexander Belyak >Priority: Major > Attachments: IGNITE-20030.zip > > > > {noformat} > drop table if exists testt; > create table testt (id int, val int, id2 int not null, val2 varchar(255), > primary key(id,id2) ); > insert into testt(id, val, id2, val2) > values(1,1,1,'1'),(2,2,2,'2'),(3,3,3,'3'); > delete from testt where id = 2; > delete from testt where id = 2 and id2 = 2;{noformat} > Expected result: row deleted without errors > > Actual result: > > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=delete > from testt where id = 2]. Error message:Query remote fragment execution > failed: nodeName=SmokeOdbcTest_cluster_0, > queryId=d47ef0ae-65dd-4762-8e6b-0b40e0333d27, fragmentId=1793, > originalMessage=null{noformat} > Logs in attachment. > > AI3 commit id: f34beaed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20030) Delete from table with composite PK failed
[ https://issues.apache.org/jira/browse/IGNITE-20030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-20030: -- Summary: Delete from table with composite PK failed (was: Delete from table failed if ) > Delete from table with composite PK failed > -- > > Key: IGNITE-20030 > URL: https://issues.apache.org/jira/browse/IGNITE-20030 > Project: Ignite > Issue Type: Task >Reporter: Alexander Belyak >Priority: Major > Attachments: IGNITE-20030.zip > > > > {noformat} > drop table if exists testt; > create table testt (id int, val int, id2 int not null, val2 varchar(255), > primary key(id,id2) ); > insert into testt(id, val, id2, val2) > values(1,1,1,'1'),(2,2,2,'2'),(3,3,3,'3'); > delete from testt where id = 2; > delete from testt where id = 2 and id2 = 2;{noformat} > Expected result: row deleted without errors > > Actual result: > > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=delete > from testt where id = 2]. Error message:Query remote fragment execution > failed: nodeName=SmokeOdbcTest_cluster_0, > queryId=d47ef0ae-65dd-4762-8e6b-0b40e0333d27, fragmentId=1793, > originalMessage=null{noformat} > Logs in attachment. > > AI3 commit id: f34beaed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20030) Delete from table failed if
Alexander Belyak created IGNITE-20030: - Summary: Delete from table failed if Key: IGNITE-20030 URL: https://issues.apache.org/jira/browse/IGNITE-20030 Project: Ignite Issue Type: Task Reporter: Alexander Belyak {noformat} drop table if exists testt; create table testt (id int, val int, id2 int not null, val2 varchar(255), primary key(id,id2) ); insert into testt(id, val, id2, val2) values(1,1,1,'1'),(2,2,2,'2'),(3,3,3,'3'); delete from testt where id = 2; delete from testt where id = 2 and id2 = 2;{noformat} Expected result: row deleted without errors Actual result: {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=delete from testt where id = 2]. Error message:Query remote fragment execution failed: nodeName=SmokeOdbcTest_cluster_0, queryId=d47ef0ae-65dd-4762-8e6b-0b40e0333d27, fragmentId=1793, originalMessage=null{noformat} Logs in attachment. AI3 commit id: f34beaed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-19691) Drop column ignore "if exists" clause
[ https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak closed IGNITE-19691. - > Drop column ignore "if exists" clause > - > > Key: IGNITE-19691 > URL: https://issues.apache.org/jira/browse/IGNITE-19691 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 > Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Scenario: > 1) create table > 2) drop some columns > 3) drop same columns with "if exists" > Expected results: execute without errors; > Actual results: last ddl instruction return SQLException > > {noformat} > create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null, > primary key (c1, c2)); > alter table tA drop column (v0, v1); > alter table tA drop column if exists (v0, v1);{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19691) Drop column ignore "if exists" clause
[ https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742008#comment-17742008 ] Alexander Belyak commented on IGNITE-19691: --- Now DDL script: {code:java} create table test(id int primary key, val int); alter table test drop column if exists val; {code} returns expected error: {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=alter table test drop column if exists val]. Error message:Failed to parse query: Encountered "" at line 1, column 30. Was expecting one of: {noformat} > Drop column ignore "if exists" clause > - > > Key: IGNITE-19691 > URL: https://issues.apache.org/jira/browse/IGNITE-19691 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 > Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Scenario: > 1) create table > 2) drop some columns > 3) drop same columns with "if exists" > Expected results: execute without errors; > Actual results: last ddl instruction return SQLException > > {noformat} > create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null, > primary key (c1, c2)); > alter table tA drop column (v0, v1); > alter table tA drop column if exists (v0, v1);{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19691) Drop column ignore "if exists" clause
[ https://issues.apache.org/jira/browse/IGNITE-19691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-19691. --- Resolution: Won't Fix > Drop column ignore "if exists" clause > - > > Key: IGNITE-19691 > URL: https://issues.apache.org/jira/browse/IGNITE-19691 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 > Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Scenario: > 1) create table > 2) drop some columns > 3) drop same columns with "if exists" > Expected results: execute without errors; > Actual results: last ddl instruction return SQLException > > {noformat} > create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null, > primary key (c1, c2)); > alter table tA drop column (v0, v1); > alter table tA drop column if exists (v0, v1);{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19816) View support
[ https://issues.apache.org/jira/browse/IGNITE-19816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19816: -- Labels: ignite-3 (was: ) > View support > > > Key: IGNITE-19816 > URL: https://issues.apache.org/jira/browse/IGNITE-19816 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Create view not supported: > {noformat} > drop table if exists vbase; > create table vbase(key int primary key, val int) ; > > create view v1(k,v) as > select key, val from vbase; {noformat} > returns error > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=create > view v1(k,v) as > select key, val from vbase]. Error message:Failed to parse query: Encountered > "" at line 1, column 1. > Was expecting one of: > {noformat} > and there is nothing about view in the documentation > https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19816) View support
Alexander Belyak created IGNITE-19816: - Summary: View support Key: IGNITE-19816 URL: https://issues.apache.org/jira/browse/IGNITE-19816 Project: Ignite Issue Type: Task Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Create view not supported: {noformat} drop table if exists vbase; create table vbase(key int primary key, val int) ; create view v1(k,v) as select key, val from vbase; {noformat} returns error {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=create view v1(k,v) as select key, val from vbase]. Error message:Failed to parse query: Encountered "" at line 1, column 1. Was expecting one of: {noformat} and there is nothing about view in the documentation https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19813) Unable to execute TPCH Q2 query
Alexander Belyak created IGNITE-19813: - Summary: Unable to execute TPCH Q2 query Key: IGNITE-19813 URL: https://issues.apache.org/jira/browse/IGNITE-19813 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Executing for standatd TPC-H query Q2 took few minutes. Not work neither as Plain test nor PreparedStatement {code:java} SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment FROM part, supplier, partsupp, nation, region WHERE p_partkey = ps_partkey AND s_suppkey = ps_suppkey AND p_size = 12 AND p_type LIKE '%NICKEL' AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'AFRICA' AND ps_supplycost = ( SELECT MIN(ps_supplycost) FROM partsupp, supplier, nation, region WHERE p_partkey = ps_partkey AND s_suppkey = ps_suppkey AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'AFRICA' ) ORDER BY s_acctbal DESC, n_name, s_name, p_partkey LIMIT 100 {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19727) Server nodes cannot find each other and log NullPointerException
[ https://issues.apache.org/jira/browse/IGNITE-19727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19727: -- Labels: ignite-3 (was: ) > Server nodes cannot find each other and log NullPointerException > > > Key: IGNITE-19727 > URL: https://issues.apache.org/jira/browse/IGNITE-19727 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Critical > Labels: ignite-3 > Attachments: server1.log.zip, server2.log.zip > > > h2. Steps to reproduce > # Version 3.0.0-SNAPSHOT commit hash 006ddb06e1deb6788e1b2796bc033af14758b132 > # Copy db distributions into 2 servers. > # Setup log level to FINE > # Setup lookup by changing ignite-config.conf on both servers to > {code:java} > { > network: { > port: 3344, > portRange: 10, > nodeFinder: { > netClusterNodes: [ > "172.24.1.2:3344,172.24.1.4:3344" > ] > } > } > } {code} > # Start both servers by command > {code:java} > sh ./ignite3db start {code} > > h2. Expected behavior > Servers joined into cluster. > h2. Actual behavior > Two separate clusters are created with errors in log such: > {code:java} > 2023-06-13 16:21:07:178 + [WARNING][main][MembershipProtocol] > [default:defaultNode:57294ce834dc4730@172.24.1.2:3344] Exception on initial > Sync, cause: java.lang.NullPointerException > ... > 2023-06-13 16:21:37:185 + [DEBUG][sc-cluster-3344-1][MembershipProtocol] > [default:defaultNode:57294ce834dc4730@172.24.1.2:3344][doSync] Send Sync to > 172.24.1.2:3344,172.24.1.4:3344 > 2023-06-13 16:21:37:186 + [DEBUG][sc-cluster-3344-1][MembershipProtocol] > [default:defaultNode:57294ce834dc4730@172.24.1.2:3344][doSync] Failed to send > Sync to 172.24.1.2:3344,172.24.1.4:3344, cause: > java.lang.NullPointerException {code} > Logs in attachment[^server1.log.zip][^server2.log.zip] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19703) Unable to create schema via SQL
Alexander Belyak created IGNITE-19703: - Summary: Unable to create schema via SQL Key: IGNITE-19703 URL: https://issues.apache.org/jira/browse/IGNITE-19703 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Error while executing "CREATE SCHEMA s1" {noformat} Exception while executing query [query=CREATE SCHEMA S1]. Error message:Failed to parse query: Encountered "" at line 1, column 1. Was expecting one of: java.sql.SQLException: Exception while executing query [query=CREATE SCHEMA S1]. Error message:Failed to parse query: Encountered "" at line 1, column 1. Was expecting one of: at org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57) at org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149) at org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:178) at org.gridgain.ai3tests.tests.DefaultValueTests.createIfNotExistsSameTablesInDifferentScemas(DefaultValueTests.java:194) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCol
[jira] [Created] (IGNITE-19702) Unable to create column with default value with literal convertion
Alexander Belyak created IGNITE-19702: - Summary: Unable to create column with default value with literal convertion Key: IGNITE-19702 URL: https://issues.apache.org/jira/browse/IGNITE-19702 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak DDL command to create a column with default value fails if it require some type of conversion (string to time, date, timestamp, uuid). For example: {noformat} create table ttt6(key int primary key, val TIMESTAMP default '2022-02-01 12:12:12');{noformat} returns {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=create table ttt6(key int primary key, val TIMESTAMP default '2022-02-01 12:12:12')]. Error message:Unable co convert literal{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19701) Type exception on insert into uuid columns with gen_random_uuid
Alexander Belyak created IGNITE-19701: - Summary: Type exception on insert into uuid columns with gen_random_uuid Key: IGNITE-19701 URL: https://issues.apache.org/jira/browse/IGNITE-19701 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Step to reproduce: {noformat} create table tdd(a uuid default gen_random_uuid, b int, primary key (a) ); insert into tdd(b) values(22) {noformat} Expected result: row with autogenerated primary key a inserted Actual result: {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=insert into tdd(b) values(22)]. Error message:Query remote fragment execution failed: nodeName=DropColumnsTest_cluster_1, queryId=e0a9b944-74a5-4d9d-a4a9-7962cb821c81, fragmentId=20, originalMessage=storageType is class java.util.UUID value must also be class java.util.UUID but it was: 1726917f-f47f-4ccc-94a0-59ac518e101b{noformat} It is possibly to insert row with generated UUID: {noformat} insert into tdd(a, b) values('1726917f-f47f-4ccc-94a0-59ac518e101b', 22){noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19691) Drop column ignore "if exists" clause
Alexander Belyak created IGNITE-19691: - Summary: Drop column ignore "if exists" clause Key: IGNITE-19691 URL: https://issues.apache.org/jira/browse/IGNITE-19691 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Environment: AI3, commit id 612f08f6 on 08.06.2023 at 15:01 Reporter: Alexander Belyak Scenario: 1) create table 2) drop some columns 3) drop same columns with "if exists" Expected results: execute without errors; Actual results: last ddl instruction return SQLException {noformat} create table tA(v0 INTEGER, c2 INTEGER, v1 INTEGER, c1 INTEGER not null, primary key (c1, c2)); alter table tA drop column (v0, v1); alter table tA drop column if exists (v0, v1);{noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19621) Slow query planning
[ https://issues.apache.org/jira/browse/IGNITE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19621: -- Description: Query from the TPC-H benchmark took 13 to 18 seconds to plan (try to execute on an empty TPCH tables) Problem query is: {code:java} select sum(case when nation = '' then volume else 0 end) / sum(volume) as mkt_share , o_year from ( select floor(o_orderdate / (cast (365 as bigint) * 8640)) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation from part, supplier, lineitem, orders, customer, nation n1, nation n2, region where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = 'rrr2' and s_nationkey = n2.n_nationkey and o_orderdate between 78890400 and 85197240 and p_type = ) as all_nations group by o_year order by o_year {code} Second run took about 50ms (query cache works fine). See ddl in attachment. was: Query from the TPC-H benchmark took 13 to 18 seconds to plan (try to execute on an empty TPCH tables) Problem query is: {code:java} select sum(case when nation = '' then volume else 0 end) / sum(volume) as mkt_share , o_year from ( select floor(o_orderdate / (cast (365 as bigint) * 8640)) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation from part, supplier, lineitem, orders, customer, nation n1, nation n2, region where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = 'rrr2' and s_nationkey = n2.n_nationkey and o_orderdate between 78890400 and 85197240 and p_type = ) as all_nations group by o_year order by o_year {code} Second run took about 50ms (query cache works fine). > Slow query planning > --- > > Key: IGNITE-19621 > URL: https://issues.apache.org/jira/browse/IGNITE-19621 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: ddl-ignite3.sql > > > Query from the TPC-H benchmark took 13 to 18 seconds to plan (try to execute > on an empty TPCH tables) > Problem query is: > {code:java} > select sum(case when nation = '' then volume else 0 end) / sum(volume) > as mkt_share , o_year > from ( > select floor(o_orderdate / (cast (365 as bigint) * 8640)) as o_year, > l_extendedprice * (1 - l_discount) as volume, > n2.n_name as nation > from part, supplier, lineitem, orders, customer, nation n1, nation n2, > region > where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = > o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey > and n1.n_regionkey = r_regionkey and r_name = 'rrr2' and s_nationkey = > n2.n_nationkey > and o_orderdate between 78890400 and 85197240 > and p_type = > ) as all_nations > group by o_year > order by o_year > {code} > Second run took about 50ms (query cache works fine). > See ddl in attachment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19621) Slow query planning
[ https://issues.apache.org/jira/browse/IGNITE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19621: -- Attachment: ddl-ignite3.sql > Slow query planning > --- > > Key: IGNITE-19621 > URL: https://issues.apache.org/jira/browse/IGNITE-19621 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: ddl-ignite3.sql > > > Query from the TPC-H benchmark took 13 to 18 seconds to plan (try to execute > on an empty TPCH tables) > Problem query is: > {code:java} > select sum(case when nation = '' then volume else 0 end) / sum(volume) > as mkt_share , o_year > from ( > select floor(o_orderdate / (cast (365 as bigint) * 8640)) as o_year, > l_extendedprice * (1 - l_discount) as volume, > n2.n_name as nation > from part, supplier, lineitem, orders, customer, nation n1, nation n2, > region > where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = > o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey > and n1.n_regionkey = r_regionkey and r_name = 'rrr2' and s_nationkey = > n2.n_nationkey > and o_orderdate between 78890400 and 85197240 > and p_type = > ) as all_nations > group by o_year > order by o_year > {code} > Second run took about 50ms (query cache works fine). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19621) Slow query planning
Alexander Belyak created IGNITE-19621: - Summary: Slow query planning Key: IGNITE-19621 URL: https://issues.apache.org/jira/browse/IGNITE-19621 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Query from the TPC-H benchmark took 13 to 18 seconds to plan (try to execute on an empty TPCH tables) Problem query is: {code:java} select sum(case when nation = '' then volume else 0 end) / sum(volume) as mkt_share , o_year from ( select floor(o_orderdate / (cast (365 as bigint) * 8640)) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation from part, supplier, lineitem, orders, customer, nation n1, nation n2, region where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = 'rrr2' and s_nationkey = n2.n_nationkey and o_orderdate between 78890400 and 85197240 and p_type = ) as all_nations group by o_year order by o_year {code} Second run took about 50ms (query cache works fine). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19552) ArrayStoreException on connect to remote server node
[ https://issues.apache.org/jira/browse/IGNITE-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19552: -- Description: The problem consistently reproduces with the remote server node, sometimes - with the local one on AI3 after {color:#d1d2d3}a4912c63 IGNITE-19318 Unable to build stand alone/fat jar with JDBC driver (#2048){color}. 1) Start single server node 2) Active cluster 3) Connect to the cluster via JDBC driver. Expected result: connection established Actual result: {code:java} [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - R:/127.0.0.1:53528]java.lang.ArrayStoreException: org.apache.ignite.internal.client.proto.ClientMessageDecoderat org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514) at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429) at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486) at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) {code} was: The problem consistently reproduces with the remote server node, sometimes - with the local one on AI3 after {color:#d1d2d3}a4912c63 IGNITE-19318 Unable to build stand alone/fat jar with JDBC driver (#2048){color}. 1) Start single server node 2) Active cluster 3) Connect to the cluster via JDBC driver. Expected result: connection established Actual result: {code:java} [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - R:/127.0.0.1:53528]java.lang.ArrayStoreException: org.apache.ignite.internal.client.proto.ClientMessageDecoderat org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.j
[jira] [Commented] (IGNITE-19552) ArrayStoreException on connect to remote server node
[ https://issues.apache.org/jira/browse/IGNITE-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725802#comment-17725802 ] Alexander Belyak commented on IGNITE-19552: --- Problem was related to IGNITE-19318, due to installing fat JDBC jar into the local maven repo on my host. > ArrayStoreException on connect to remote server node > > > Key: IGNITE-19552 > URL: https://issues.apache.org/jira/browse/IGNITE-19552 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 3.0 >Reporter: Alexander Belyak >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > The problem consistently reproduces with the remote server node, sometimes - > with the local one on AI3 after {color:#d1d2d3}a4912c63 IGNITE-19318 Unable > to build stand alone/fat jar with JDBC driver (#2048){color}. > 1) Start single server node > 2) Active cluster > 3) Connect to the cluster via JDBC driver. > Expected result: connection established > Actual result: > {code:java} > [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS > usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, > field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 > VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 > PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to > initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - > R:/127.0.0.1:53528]java.lang.ArrayStoreException: > org.apache.ignite.internal.client.proto.ClientMessageDecoderat > org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) > at > io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) > at > io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) >at > io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) > at > io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) > at > io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) > at > io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) > at > io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) > at > io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) > at > io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514) > at > io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429) > at > io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486) > at > io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) > at > io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) > at > io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at > io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) > at > io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.base/java.lang.Thread.run(Thread.java:829) {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19552) ArrayStoreException on connect to remote server node
[ https://issues.apache.org/jira/browse/IGNITE-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19552: -- Description: The problem consistently reproduces with the remote server node, sometimes - with the local one on AI3 after {color:#d1d2d3}a4912c63 IGNITE-19318 Unable to build stand alone/fat jar with JDBC driver (#2048){color}. 1) Start single server node 2) Active cluster 3) Connect to the cluster via JDBC driver. Expected result: connection established Actual result: {code:java} [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - R:/127.0.0.1:53528]java.lang.ArrayStoreException: org.apache.ignite.internal.client.proto.ClientMessageDecoderat org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514) at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429) at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486) at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) {code} Important - use one of the last builds. was: The problem consistently reproduces with the remote server node, sometimes - with local one. 1) Start single server node 2) Active cluster 3) Connect to the cluster via JDBC driver. Expected result: connection established Actual result: {code:java} [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - R:/127.0.0.1:53528]java.lang.ArrayStoreException: org.apache.ignite.internal.client.proto.ClientMessageDecoderat org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514) at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractC
[jira] [Created] (IGNITE-19552) ArrayStoreException on connect to remote server node
Alexander Belyak created IGNITE-19552: - Summary: ArrayStoreException on connect to remote server node Key: IGNITE-19552 URL: https://issues.apache.org/jira/browse/IGNITE-19552 Project: Ignite Issue Type: Bug Components: jdbc Affects Versions: 3.0 Reporter: Alexander Belyak The problem consistently reproduces with the remote server node, sometimes - with local one. 1) Start single server node 2) Active cluster 3) Connect to the cluster via JDBC driver. Expected result: connection established Actual result: {code:java} [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 - R:/127.0.0.1:53528]java.lang.ArrayStoreException: org.apache.ignite.internal.client.proto.ClientMessageDecoderat org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112) at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514) at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429) at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486) at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) {code} Important - use one of the last builds. TBD: environment details and particular commit with the bug. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19480) ThinClient hangs on error
Alexander Belyak created IGNITE-19480: - Summary: ThinClient hangs on error Key: IGNITE-19480 URL: https://issues.apache.org/jira/browse/IGNITE-19480 Project: Ignite Issue Type: Bug Components: clients Affects Versions: 3.0 Reporter: Alexander Belyak ThinClient hangs on any error: {code:java} @Test public void testThinClientHangs() throws Exception { try (IgniteClient igniteClient = IgniteClient.builder().addresses("localhost:10800").build(); Session session = igniteClient.sql().createSession()) { try { session.execute(null, "select * from tableNotExists"); } catch (Throwable t) { System.err.println("Got exception " + t.getMessage()); } System.out.println("DONE"); } } {code} doesn't get to the DONE, just hangs: {noformat} 18:21:44.112 [Test worker] DEBUG io.netty.util.internal.logging.InternalLoggerFactory -- Using SLF4J as the default logging framework 18:21:44.114 [Test worker] DEBUG io.netty.channel.MultithreadEventLoopGroup -- -Dio.netty.eventLoopThreads: 16 18:21:44.159 [Test worker] DEBUG io.netty.util.internal.InternalThreadLocalMap -- -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024 18:21:44.159 [Test worker] DEBUG io.netty.util.internal.InternalThreadLocalMap -- -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096 18:21:44.224 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- -Dio.netty.noUnsafe: false 18:21:44.225 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- Java version: 11 18:21:44.227 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- sun.misc.Unsafe.theUnsafe: available 18:21:44.229 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- sun.misc.Unsafe.copyMemory: available 18:21:44.231 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- sun.misc.Unsafe.storeFence: available 18:21:44.232 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- java.nio.Buffer.address: available 18:21:44.233 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- direct buffer constructor: unavailable: Reflective setAccessible(true) disabled 18:21:44.234 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- java.nio.Bits.unaligned: available, true 18:21:44.236 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- jdk.internal.misc.Unsafe.allocateUninitializedArray(int): unavailable: class io.netty.util.internal.PlatformDependent0$7 cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @16b3fc9e 18:21:44.238 [Test worker] DEBUG io.netty.util.internal.PlatformDependent0 -- java.nio.DirectByteBuffer.(long, int): unavailable 18:21:44.239 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- sun.misc.Unsafe: available 18:21:44.240 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- maxDirectMemory: 536870912 bytes (maybe) 18:21:44.240 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- -Dio.netty.tmpdir: /tmp (java.io.tmpdir) 18:21:44.240 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- -Dio.netty.bitMode: 64 (sun.arch.data.model) 18:21:44.242 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- -Dio.netty.maxDirectMemory: -1 bytes 18:21:44.242 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- -Dio.netty.uninitializedArrayAllocationThreshold: -1 18:21:44.244 [Test worker] DEBUG io.netty.util.internal.CleanerJava9 -- java.nio.ByteBuffer.cleaner(): available 18:21:44.244 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- -Dio.netty.noPreferDirect: false 18:21:44.248 [Test worker] DEBUG io.netty.channel.nio.NioEventLoop -- -Dio.netty.noKeySetOptimization: false 18:21:44.248 [Test worker] DEBUG io.netty.channel.nio.NioEventLoop -- -Dio.netty.selectorAutoRebuildThreshold: 512 18:21:44.273 [Test worker] DEBUG io.netty.util.internal.PlatformDependent -- org.jctools-core.MpscChunkedArrayQueue: available 18:21:44.360 [Test worker] DEBUG io.netty.channel.DefaultChannelId -- -Dio.netty.processId: 91839 (auto-detected) 18:21:44.369 [Test worker] DEBUG io.netty.util.NetUtil -- -Djava.net.preferIPv4Stack: false 18:21:44.370 [Test worker] DEBUG io.netty.util.NetUtil -- -Djava.net.preferIPv6Addresses: false 18:21:44.375 [Test worker] DEBUG io.netty.util.NetUtilInitializations -- Loopback interface: lo (lo, 0:0:0:0:0:0:0:1%lo) 18:21:44.378 [Test worker] DEBUG io.netty.util.NetUtil -- /proc/sys/net/core/somaxconn: 4096 18:21:44.380 [Test worker] DEBUG io.netty.channel.DefaultChannelId -- -Dio.netty.machineId: 00:16:3e:ff:fe:00:00:00 (auto-detected) 18:21:44.417 [Test worker] DEBUG io.netty.util.ResourceLeakDetector -- -Dio.netty.leakDetection.level: simple 18:21:44.419 [Test worker] DEBUG io.n
[jira] [Commented] (IGNITE-19442) Data corruption on huge numeric values
[ https://issues.apache.org/jira/browse/IGNITE-19442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721861#comment-17721861 ] Alexander Belyak commented on IGNITE-19442: --- Same with date: {noformat} create table test(k TIMESTAMP not null, v INTEGER not null, primary key (k)) insert into test(k, v) values('+4558399-06-20 05:47:19.0', 116513) select * from test{noformat} returns {noformat} K V 8399-06-20T05:47:19 116513{noformat} Insert command for such values returns success. > Data corruption on huge numeric values > -- > > Key: IGNITE-19442 > URL: https://issues.apache.org/jira/browse/IGNITE-19442 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Simple scenario: > {noformat} > create table t17 (key numeric primary key, val varchar(3)); > insert into t17 values(1,'1'); > insert into t17 values(99,'1'); > select * from t17;{noformat} > returns > {noformat} > key val > 8023796054858137599 1 > 1 1 > {noformat} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19442) Data corruption on huge numeric values
Alexander Belyak created IGNITE-19442: - Summary: Data corruption on huge numeric values Key: IGNITE-19442 URL: https://issues.apache.org/jira/browse/IGNITE-19442 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Simple scenario: {noformat} create table t17 (key numeric primary key, val varchar(3)); insert into t17 values(1,'1'); insert into t17 values(99,'1'); select * from t17;{noformat} returns {noformat} key val 8023796054858137599 1 1 1 {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19383) Add commit hash to log
Alexander Belyak created IGNITE-19383: - Summary: Add commit hash to log Key: IGNITE-19383 URL: https://issues.apache.org/jira/browse/IGNITE-19383 Project: Ignite Issue Type: Improvement Affects Versions: 3.0 Reporter: Alexander Belyak Let's add commit hash into the log message: {code:java} INFO: # ___ __ ### / | _ _ / /_ ___ # # / /| | / __ \ / __ `// ___// __ \ / _ \ ### ## / ___ | / /_/ // /_/ // /__ / / / // ___/ # ### /_/ |_|/ .___/ \__,_/ \___//_/ /_/ \___/ ### ## /_/ _ __ _ # ## / _/ _ (_)/ /_ ___ |__ / ### # / / / __ `// __ \ / // __// _ \ /_ < # # _/ / / /_/ // / / // // /_ / ___/ ___/ / ## /___/ \__, //_/ /_//_/ \__/ \___/ // ## // Apache Ignite ver. 3.0.0-SNAPSHOT {code} after the version -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19366) Monitoring in AI3
Alexander Belyak created IGNITE-19366: - Summary: Monitoring in AI3 Key: IGNITE-19366 URL: https://issues.apache.org/jira/browse/IGNITE-19366 Project: Ignite Issue Type: Bug Affects Versions: 3.0 Reporter: Alexander Belyak AI3 needs some monitoring tools ready prior to the first production installation. In my opinion, firstly we need to make some documentation with: 1) the first set of monitoring tools (enlist each aspect of what should be done) 2) high level describe each element and try to mark its difficulty 3) split the implementation into phases: must have, should have, nice to have >From my point of view, the most crucial thing is database locks. AI3 should be >able to show what (who and for how long) prevents transaction processing. To show it AI3 may provide: * a system table/view with all transactions with at least one active lock/lock attempt, its id and id(s) of the tx it's waiting for. * ability to log some debug info into the log when a transaction is killed by a deadlock prevention mechanism (not sure if it should be a part of this document) The second majority problem is long-running queries. To show it AI3 may provide: * a system table/view with all running queries/txs with their origin (client/node/username), start time, text, and id. * ability to log such queries into the log file (queries that took longer than N ms) The others can contain: * index usage monitoring * memory usage (by tables, indexes, caches, metadata) * data integrity (can the user turn off a particular cluster node or not? Was rebalance finished?) * per query resource consumption (actual read pages (from dist/mem, globally/locally?), CPU, memory for the caching) * node/cluster configuration * background processes status (index rebuild, autovacuum, schema changes background processing) Mandatory requirement - each option has to have its user documentation (and example of usage?) What it should not cover/be: * data statistics * query plans * performance tuning instructions/manuals * tuning options to prevent excessive locking/database overloading like time to live, deadlock detection/prevention mechanisms -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19320) NPE on connection close (if there was 0 operation)
Alexander Belyak created IGNITE-19320: - Summary: NPE on connection close (if there was 0 operation) Key: IGNITE-19320 URL: https://issues.apache.org/jira/browse/IGNITE-19320 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak Exception {noformat} WARNING: Exception in client connector pipeline [remoteAddress=/127.0.0.1:51586]: IGN-CMN-65535 TraceId:fb08f569-9e4a-4d15-80a6-dafdcbff7acd org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535 TraceId:fb08f569-9e4a-4d15-80a6-dafdcbff7acd at org.apache.ignite.client.handler.ClientResourceRegistry.close(ClientResourceRegistry.java:130) at org.apache.ignite.client.handler.ClientInboundMessageHandler.channelInactive(ClientInboundMessageHandler.java:225) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281) at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274) at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411) at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281) at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281) at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901) at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813) at io.netty.util.concurrent.AbstractEventExecutor.runTask$$$capture(AbstractEventExecutor.java:174) at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute$$$capture(AbstractEventExecutor.java:167) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.NullPointerException{noformat} on close connection without a single query: {code:java} public static void main(String[] args) throws InterruptedException { try (Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1:10800")) { // NoOp. } catch (SQLException e) { throw new RuntimeException(e); } } {code} Because in {color:#00}JdbcQueryEventHandlerImpl.{color}{color:#00}JdbcConnectionContext{color}.close() there is no check if connectionId is Null and SessionManager.session(SessionId) tries to get null from its {color:#0033b3}private final {color}{color:#00}Map{color}<{color:#00}SessionId{color}, {color:#00}Session{color}> {color:#871094}activeSessions {color}= {color:#0033b3}new {color}ConcurrentHashMap<>(); -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19306) Drop multiple column if exists without brace
[ https://issues.apache.org/jira/browse/IGNITE-19306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19306: -- Labels: ignite-3 (was: ) > Drop multiple column if exists without brace > > > Key: IGNITE-19306 > URL: https://issues.apache.org/jira/browse/IGNITE-19306 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Trivial > Labels: ignite-3 > > Wrong parameter name {{IF NOT EXISTS}} > [https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int] > Correct one: IF EXISTS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19305) Index alive after drop indexed column
[ https://issues.apache.org/jira/browse/IGNITE-19305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19305: -- Labels: ignite-3 (was: ) > Index alive after drop indexed column > - > > Key: IGNITE-19305 > URL: https://issues.apache.org/jira/browse/IGNITE-19305 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > In > [documentation|https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int] > I see: "If the column was indexed, the index has to be dropped manually in > advance by using the 'DROP INDEX' command." But it seems like an alpha > version limitation. > Unable to create index with the same name after dropping indexed column: > {noformat} > create table tindex( > id int primary key, > v1 int, > v2 int); > create index titest on tindex(v1, v2) > alter table tindex drop column v1; > create index titest on tindex(v2);{noformat} > error: > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=create > index titest on tindex(v2)]. Error message:IGN-SQL-17 > TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17 > TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists > [name="PUBLIC"."TITEST"]{noformat} > Expected behaviour: > 1) index titest drop while dropping v1 columnd > 2) index titest successfully created on the last DDL operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19304) Create index with the same column twice
[ https://issues.apache.org/jira/browse/IGNITE-19304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19304: -- Labels: ignite-3 (was: ) > Create index with the same column twice > --- > > Key: IGNITE-19304 > URL: https://issues.apache.org/jira/browse/IGNITE-19304 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > Labels: ignite-3 > > Unable to create index with same column twice: > {noformat} > create table tindex( > id int primary key, > v1 int, > v2 int); > create index titest on tindex(v1,v1){noformat} > error: > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=create > index titest on tindex(v1,v1)]. Error message:IGN-CMN-65535 > TraceId:203a2c0c-fbf1-4143-aa47-50c97223ad84 Named List element with key "V1" > already exists{noformat} > But documentation > [https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#create-index] do > not block it. Postgres allow to execute such DDL too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19318) Unable to build stand alone/fat jar with JDBC driver
Alexander Belyak created IGNITE-19318: - Summary: Unable to build stand alone/fat jar with JDBC driver Key: IGNITE-19318 URL: https://issues.apache.org/jira/browse/IGNITE-19318 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 3.0 Reporter: Alexander Belyak After running {noformat} gradlew ignite-jdbc:shadowJar{noformat} in modules/jdbc/build/libs/ignite-jdbc-3.0.0-SNAPSHOT-all.jar file size is only 806 bytes. {color:#d1d2d3} {color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19305) Index alive after drop indexed column
[ https://issues.apache.org/jira/browse/IGNITE-19305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-19305: -- Description: In [documentation|https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int] I see: "If the column was indexed, the index has to be dropped manually in advance by using the 'DROP INDEX' command." But it seems like an alpha version limitation. Unable to create index with the same name after dropping indexed column: {noformat} create table tindex( id int primary key, v1 int, v2 int); create index titest on tindex(v1, v2) alter table tindex drop column v1; create index titest on tindex(v2);{noformat} error: {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=create index titest on tindex(v2)]. Error message:IGN-SQL-17 TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17 TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists [name="PUBLIC"."TITEST"]{noformat} Expected behaviour: 1) index titest drop while dropping v1 columnd 2) index titest successfully created on the last DDL operation. was: Unable to create index with the same name after dropping indexed column: {noformat} create table tindex( id int primary key, v1 int, v2 int); create index titest on tindex(v1, v2) alter table tindex drop column v1; create index titest on tindex(v2);{noformat} error: {noformat} [Code: 0, SQL State: 5] Exception while executing query [query=create index titest on tindex(v2)]. Error message:IGN-SQL-17 TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17 TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists [name="PUBLIC"."TITEST"]{noformat} Expected behaviour: 1) index titest drop while dropping v1 columnd 2) index titest successfully created on the last DDL operation. > Index alive after drop indexed column > - > > Key: IGNITE-19305 > URL: https://issues.apache.org/jira/browse/IGNITE-19305 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > In > [documentation|https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int] > I see: "If the column was indexed, the index has to be dropped manually in > advance by using the 'DROP INDEX' command." But it seems like an alpha > version limitation. > Unable to create index with the same name after dropping indexed column: > {noformat} > create table tindex( > id int primary key, > v1 int, > v2 int); > create index titest on tindex(v1, v2) > alter table tindex drop column v1; > create index titest on tindex(v2);{noformat} > error: > {noformat} > [Code: 0, SQL State: 5] Exception while executing query [query=create > index titest on tindex(v2)]. Error message:IGN-SQL-17 > TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 IGN-SQL-17 > TraceId:5f61df67-cc61-4eb1-98be-3bbaa25a7c44 Index already exists > [name="PUBLIC"."TITEST"]{noformat} > Expected behaviour: > 1) index titest drop while dropping v1 columnd > 2) index titest successfully created on the last DDL operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19306) Drop multiple column if exists without brace
Alexander Belyak created IGNITE-19306: - Summary: Drop multiple column if exists without brace Key: IGNITE-19306 URL: https://issues.apache.org/jira/browse/IGNITE-19306 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Alexander Belyak Wrong parameter name {{IF NOT EXISTS}} [https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int] Correct one: IF EXISTS -- This message was sent by Atlassian Jira (v8.20.10#820010)