[jira] [Assigned] (IGNITE-24913) Fix falky TcpCommunicationSpiSslVolatilePayloadTest
[ https://issues.apache.org/jira/browse/IGNITE-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-24913: --- Assignee: Mikhail Petrov > Fix falky TcpCommunicationSpiSslVolatilePayloadTest > --- > > Key: IGNITE-24913 > URL: https://issues.apache.org/jira/browse/IGNITE-24913 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.18 > > Time Spent: 1.5h > Remaining Estimate: 0h > > See > https://ci2.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=4077873124689907116&page=1&branch_IgniteTests24Java8=%3Cdefault%3E > for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-24913) Fix falky TcpCommunicationSpiSslVolatilePayloadTest
[ https://issues.apache.org/jira/browse/IGNITE-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-24913. - Resolution: Fixed > Fix falky TcpCommunicationSpiSslVolatilePayloadTest > --- > > Key: IGNITE-24913 > URL: https://issues.apache.org/jira/browse/IGNITE-24913 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.18 > > Time Spent: 1.5h > Remaining Estimate: 0h > > See > https://ci2.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=4077873124689907116&page=1&branch_IgniteTests24Java8=%3Cdefault%3E > for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23033) .NET: Thin 3.0: Support tuples with schemas in Compute and Streamer
[ https://issues.apache.org/jira/browse/IGNITE-23033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-23033: Priority: Critical (was: Major) > .NET: Thin 3.0: Support tuples with schemas in Compute and Streamer > --- > > Key: IGNITE-23033 > URL: https://issues.apache.org/jira/browse/IGNITE-23033 > Project: Ignite > Issue Type: Improvement > Components: compute, platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET, ignite-3 > Fix For: 3.1 > > > Allow the users to use *IIgniteTuple* as a compute job argument and result, > as streamer payload/argument/result. > * See IGNITE-22643 and TODOs with this ticket number. > * See IGNITE-23186 > * See IGNITE-24469 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24840) Sql. Extend SQL logic test coverage for TIME types
[ https://issues.apache.org/jira/browse/IGNITE-24840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-24840: -- Summary: Sql. Extend SQL logic test coverage for TIME types (was: Sql. Extend SQL logic test coverage for TIME/DATE/TIMESTAMP types) > Sql. Extend SQL logic test coverage for TIME types > -- > > Key: IGNITE-24840 > URL: https://issues.apache.org/jira/browse/IGNITE-24840 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > It looks like we are missing a test for the TIME type that will check the > boundary values. > Definition of done: > * Add test test/sql/types/date/test_incorrect_times.test to verify boundary > values and supported literal form > * In test/sql/types/time/test_time.test add checks to verify different > precision 0(default), 1,2 (add corresponding columns to table and checks) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23167) Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge
[ https://issues.apache.org/jira/browse/IGNITE-23167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-23167: - Fix Version/s: 2.18 (was: 2.16) > Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge > - > > Key: IGNITE-23167 > URL: https://issues.apache.org/jira/browse/IGNITE-23167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.16 >Reporter: YuJue Li >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > Fix For: 2.18 > > Attachments: image-2024-09-09-14-55-13-666.png > > Time Spent: 1h > Remaining Estimate: 0h > > !image-2024-09-09-14-55-13-666.png! > This warning log is redundant. > When executing a MERGE statement for the first time, this warning log is > always output, which causes inconvenience to the user. However, this warning > is of no use and can be completely deleted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24840) Sql. Extend SQL logic test coverage for TIME/DATE/TIMESTAMP types
[ https://issues.apache.org/jira/browse/IGNITE-24840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-24840: -- Summary: Sql. Extend SQL logic test coverage for TIME/DATE/TIMESTAMP types (was: Sql. Extend SQL logic test coverage for TIME type) > Sql. Extend SQL logic test coverage for TIME/DATE/TIMESTAMP types > - > > Key: IGNITE-24840 > URL: https://issues.apache.org/jira/browse/IGNITE-24840 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > It looks like we are missing a test for the TIME type that will check the > boundary values. > Definition of done: > * Add test test/sql/types/date/test_incorrect_times.test to verify boundary > values and supported literal form > * In test/sql/types/time/test_time.test add checks to verify different > precision 0(default), 1,2 (add corresponding columns to table and checks) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24948) SSL Engine may not be closed properly during NIO session close.
Mikhail Petrov created IGNITE-24948: --- Summary: SSL Engine may not be closed properly during NIO session close. Key: IGNITE-24948 URL: https://issues.apache.org/jira/browse/IGNITE-24948 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Lets revisit steps that are occurred during session close: GridSelectorNioSessionImpl.close() -> .. -> GridNioSslFilter.onSessionClose() -> GridNioSslFilter.shutdownSession() -> GridNioSslHandler.writeNetBuffer() -> ... -> HeadFilter#onSessionClose -> GridNioServer#close GridNioSslFilter.shutdownSession() - closes SSL engine. GridNioSslHandler.writeNetBuffer() - asks SSL Engine to generate message with CLOSE-NOTIFY header. Which is intended to notify the SSL engine on the other side of the connection that the session has been closed. Puts this message to session's outbound buffer that will be asynchronously processes by NIO worker. GridNioServer#close - adds to the NIO worker queue "state change request" that closes the connection. AbstractNioClientWorker#bodyInternal - NIO worker handles first handles state change requests and then writes data to the socket. As a result, if connection close request and CLOSE-NOTIFY message is handled by 1 spin of NIO worker, we simply close the connection and do not send a CLOSE-NOTIFY message to the SSL Engine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23167) Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge
[ https://issues.apache.org/jira/browse/IGNITE-23167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17939105#comment-17939105 ] YuJue Li commented on IGNITE-23167: --- Thank you for your great work! > Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge > - > > Key: IGNITE-23167 > URL: https://issues.apache.org/jira/browse/IGNITE-23167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.16 >Reporter: YuJue Li >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > Fix For: 2.18 > > Attachments: image-2024-09-09-14-55-13-666.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > !image-2024-09-09-14-55-13-666.png! > This warning log is redundant. > When executing a MERGE statement for the first time, this warning log is > always output, which causes inconvenience to the user. However, this warning > is of no use and can be completely deleted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24007) [aimem] Restart node with open transaction leads to client freeze after node is started
[
https://issues.apache.org/jira/browse/IGNITE-24007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-24007:
--
Epic Link: IGNITE-24900
Ignite Flags: (was: Docs Required,Release Notes Required)
> [aimem] Restart node with open transaction leads to client freeze after node
> is started
> ---
>
> Key: IGNITE-24007
> URL: https://issues.apache.org/jira/browse/IGNITE-24007
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0, 3.0.0-beta1
> Environment: 3 nodes (each node is CMG, each node
> {color:#067d17}"{color}{color:#067d17}-Xms512m"{color},
> {color:#067d17}"-Xmx1536m{color}{color:#067d17}"{color}), each on separate
> host. Each host vCPU: 4, Memory: 32GB.
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: cluster logs-1.zip
>
>
> *Steps to reproduce:*
> # Start 3 nodes (each node is CMG, each node
> {color:#067d17}"-Xms512m"{color}, {color:#067d17}"-Xmx1536m"{color}), each on
> separate host. Each host vCPU: 4, Memory: 32GB.
> # Create 1 table
> ## Execute query: create zone if not exists "cluster_failover_3" with
> replicas=3, data_nodes_auto_adjust_scale_up=10,
> data_nodes_auto_adjust_scale_down=10, storage_profiles='default_aimem'
> ## Execute query: create TABLE failoverTest00(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_3"
> # Fill table with 1000 rows each
> # Await all partitions of all tables local state is "HEALTHY"
> # Await all partitions of all tables global state is "AVAILABLE"
> # Assert the tables has been filled, with expected row count of '1000' and
> no errors in logs
> # Assert that ignite log contains no errors or exceptions
> # Kill node and start it again with opened transactions
> #
> ## Begin IgniteSql transaction and execute insert
> ## Begin KeyValueView transaction and execute insert
> ## Begin JDBC transaction and execute insert
> ## Kill node and start it again
> 9. Wait node is ready after restart
> 10. Assert physical and logical topologies are correct
> 11. Assert the tables has been filled.
> *Expected:*
> All data present and consistent.
> *Actual:*
> Client freeze on step 11.
> [^cluster logs.zip]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24744) Java thin: Insert fails with "doWithRetry failed without exception"
[
https://issues.apache.org/jira/browse/IGNITE-24744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-24744:
Summary: Java thin: Insert fails with "doWithRetry failed without
exception" (was: Insert fails with "doWithRetry failed without exception")
> Java thin: Insert fails with "doWithRetry failed without exception"
> ---
>
> Key: IGNITE-24744
> URL: https://issues.apache.org/jira/browse/IGNITE-24744
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 3.0
>Reporter: Kirill Sizov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> *Scenario*
> Create an HA zone.
> One thread continuously inserts data.
> Another thread randomly starts and stops node
> *Expected behavior*
> All data is inserted successfully.
> *Actual behavior*
> Client fails with
> {noformat}
> Caused by: java.lang.IllegalStateException: doWithRetry failed without
> exception
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$8.copy(ExceptionUtils.java:965)
> ~[ignite-core-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:811)
> ~[ignite-core-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:613)
> ~[ignite-core-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:746)
> ~[ignite-core-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:564)
> ~[ignite-core-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.sql.ClientSql.execute(ClientSql.java:125)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at org.apache.ignite.sql.IgniteSql.execute(IgniteSql.java:90)
> ~[ignite-api-3.1.0-SNAPSHOT.jar:?]
> at
> org.gridgain.poc.framework.worker.ignite3.task.ExecuteQueryTask.executeQueries(ExecuteQueryTask.java:100)
> ~[poc-tester-ignite3-0.5.0-SNAPSHOT.jar:?]
> at
> org.gridgain.poc.framework.worker.ignite3.task.ExecuteQueryTask.body0(ExecuteQueryTask.java:82)
> ~[poc-tester-ignite3-0.5.0-SNAPSHOT.jar:?]
> ... 4 more
> Caused by: java.util.concurrent.CompletionException:
> java.lang.IllegalStateException: doWithRetry failed without exception
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1177)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2341)
> ~[?:?]
> at
> org.apache.ignite.internal.client.ReliableChannel.lambda$serviceAsync$2(ReliableChannel.java:257)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientFutureUtils.doWithRetryAsync(ClientFutureUtils.java:56)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientFutureUtils.doWithRetryAsync(ClientFutureUtils.java:45)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ReliableChannel.serviceAsync(ReliableChannel.java:255)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ReliableChannel.serviceAsync(ReliableChannel.java:276)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.sql.ClientSql.executeAsync(ClientSql.java:284)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.sql.ClientSql.executeAsync(ClientSql.java:220)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.sql.ClientSql.execute(ClientSql.java:123)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at org.apache.ignite.sql.IgniteSql.execute(IgniteSql.java:90)
> ~[ignite-api-3.1.0-SNAPSHOT.jar:?]
> at
> org.gridgain.poc.framework.worker.ignite3.task.ExecuteQueryTask.executeQueries(ExecuteQueryTask.java:100)
> ~[poc-tester-ignite3-0.5.0-SNAPSHOT.jar:?]
> at
> org.gridgain.poc.framework.worker.ignite3.task.ExecuteQueryTask.body0(ExecuteQueryTask.java:82)
> ~[poc-tester-ignite3-0.5.0-SNAPSHOT.jar:?]
> ... 4 more
> Caused by: java.lang.IllegalStateException: doWithRetry failed without
> exception
> at
> org.apache.ignite.internal.client.ClientFutureUtils.lambda$doWithRetryAsync$0(ClientFutureUtils.java:78)
> ~[ignite-client-3.1.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
> ~[?:?] {noformat}
> There is an exception
[jira] [Created] (IGNITE-24938) Ignore attempts to create index storage in destroyed table storage
Roman Puchkovskiy created IGNITE-24938: -- Summary: Ignore attempts to create index storage in destroyed table storage Key: IGNITE-24938 URL: https://issues.apache.org/jira/browse/IGNITE-24938 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24937) Properly process evicted pages during throttling
Ivan Bessonov created IGNITE-24937:
--
Summary: Properly process evicted pages during throttling
Key: IGNITE-24937
URL: https://issues.apache.org/jira/browse/IGNITE-24937
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
{{SpeedBasedMemoryConsumptionThrottlingStrategy#notEvictedPagesTotal}}
misbehaves, because we include evicted pages in total checkpointed pages, which
could lead to writing more pages than "notEvictedPagesTotal" would return.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24939) Improve troubleshooting documentation section.
Andrey Mashenkov created IGNITE-24939:
-
Summary: Improve troubleshooting documentation section.
Key: IGNITE-24939
URL: https://issues.apache.org/jira/browse/IGNITE-24939
Project: Ignite
Issue Type: Improvement
Components: documentation
Reporter: Andrey Mashenkov
Ignite 2 requires Java 11 or later version to start.
Since Java 9, some JVM options were deprecated and then removed [1], but we
still use them in our documentation [2].
Let's fix documentation and replace outdated JVM options with new ones.
{code:java}
Old: -XX:+PrintGCDetails
New: -Xlog:gc*
Old: -Xloggc:
New: -Xlog:gc:
{code}
[1] https://bugs.openjdk.org/browse/JDK-8145180
[2]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24939) Improve troubleshooting documentation section.
[
https://issues.apache.org/jira/browse/IGNITE-24939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-24939:
--
Description:
Ignite 2 requires Java 11 or later version to start.
Since Java 9, some JVM options were deprecated and then removed [1], but we
still use them in our documentation [2].
Let's fix documentation and replace outdated JVM options with new ones using
the guide [3]
{code:java}
Old: -XX:+PrintGCDetails
New: -Xlog:gc*
Old: -Xloggc:
New: -Xlog:gc:
{code}
Unsupported options:
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=100M
[1] https://bugs.openjdk.org/browse/JDK-8145180
[2]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
[3]
https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1
was:
Ignite 2 requires Java 11 or later version to start.
Since Java 9, some JVM options were deprecated and then removed [1], but we
still use them in our documentation [2].
Let's fix documentation and replace outdated JVM options with new ones using
the guide [3]
{code:java}
Old: -XX:+PrintGCDetails
New: -Xlog:gc*
Old: -Xloggc:
New: -Xlog:gc:
Old: -XX:+PrintGCTimeStamps
New: Not Applicable. Time stamps are logged by the framework.
Old: -XX:+PrintGCDateStamps
New: Not Applicable. Date stamps are logged by the framework.
{code}
[1] https://bugs.openjdk.org/browse/JDK-8145180
[2]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
[3]
https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1
> Improve troubleshooting documentation section.
> --
>
> Key: IGNITE-24939
> URL: https://issues.apache.org/jira/browse/IGNITE-24939
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-2
>
> Ignite 2 requires Java 11 or later version to start.
> Since Java 9, some JVM options were deprecated and then removed [1], but we
> still use them in our documentation [2].
> Let's fix documentation and replace outdated JVM options with new ones using
> the guide [3]
> {code:java}
> Old: -XX:+PrintGCDetails
> New: -Xlog:gc*
> Old: -Xloggc:
> New: -Xlog:gc:
> {code}
> Unsupported options:
> -XX:+PrintGCTimeStamps
> -XX:+PrintGCDateStamps
> -XX:+UseGCLogFileRotation
> -XX:NumberOfGCLogFiles=10
> -XX:GCLogFileSize=100M
> [1] https://bugs.openjdk.org/browse/JDK-8145180
> [2]
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
> [3]
> https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24936) Sql. Rename virtual column "__part" to allow access without quoting
Konstantin Orlov created IGNITE-24936:
-
Summary: Sql. Rename virtual column "__part" to allow access
without quoting
Key: IGNITE-24936
URL: https://issues.apache.org/jira/browse/IGNITE-24936
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
Currently, column representing partition id is registered in lower case, which
make it necessary to wrap {{__part}} in double quotes. To allow unquoted
access, we need to register this column in upper case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24935) Switch MvTableStorage to create*Index methods
[ https://issues.apache.org/jira/browse/IGNITE-24935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24935: --- Description: MvTableStorage contains methods that either get existing index partition storage or create a new one and return the result, but # we always use them in situations where we know that we need to create a storage # we never need the returned value We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to createHashIndex() and createSortedIndex(), respectively. This will allow us to make a quick and dirty fix for IGNITE-24926 which causes IGNITE-24885. Also, getOrCreateIndex() method is not used in production code, so it should be removed. was: MvTableStorage contains methods that either get existing index partition storage or create a new one and return the result, but # we always use them in situations where we know that we need to create a storage # we never need the returned value We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to createHashIndex() and createSortedIndex(), respectively. This will allow us to make a quick and dirty fix for IGNITE-24926. Also, getOrCreateIndex() method is not used in production code, so it should be removed. > Switch MvTableStorage to create*Index methods > - > > Key: IGNITE-24935 > URL: https://issues.apache.org/jira/browse/IGNITE-24935 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > MvTableStorage contains methods that either get existing index partition > storage or create a new one and return the result, but > # we always use them in situations where we know that we need to create a > storage > # we never need the returned value > We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to > createHashIndex() and createSortedIndex(), respectively. This will allow us > to make a quick and dirty fix for IGNITE-24926 which causes IGNITE-24885. > Also, getOrCreateIndex() method is not used in production code, so it should > be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24881) ItTableScanTest.testScanWithUpperBound is flaky
[
https://issues.apache.org/jira/browse/IGNITE-24881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24881:
-
Description:
Aforementioned test may fail with
{code:java}
java.lang.AssertionError: Exception has not been thrown. at
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCode(IgniteTestUtils.java:320)
at
org.apache.ignite.internal.table.ItTableScanTest.testScanWithUpperBound(ItTableScanTest.java:630)
{code}
on
{code:java}
IgniteTestUtils.assertThrowsWithCode(
TransactionException.class,
Transactions.ACQUIRE_LOCK_ERR,
() -> kvView.put(null, Tuple.create().set("key", 9),
Tuple.create().set("valInt", 9).set("valStr", "New_9")),
"Failed to acquire a lock due to a possible deadlock"); {code}
[TC
link|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8963724]
Reproduced locally 1/10.
or sometimes with
{code:java}
org.opentest4j.AssertionFailedError: expected: <3> but was: <0> at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at
app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531) at
app//org.apache.ignite.internal.table.ItTableScanTest.testScanWithUpperBound(ItTableScanTest.java:656)
{code}
> ItTableScanTest.testScanWithUpperBound is flaky
> ---
>
> Key: IGNITE-24881
> URL: https://issues.apache.org/jira/browse/IGNITE-24881
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
>
> Aforementioned test may fail with
> {code:java}
> java.lang.AssertionError: Exception has not been thrown. at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCode(IgniteTestUtils.java:320)
> at
> org.apache.ignite.internal.table.ItTableScanTest.testScanWithUpperBound(ItTableScanTest.java:630)
> {code}
> on
> {code:java}
> IgniteTestUtils.assertThrowsWithCode(
> TransactionException.class,
> Transactions.ACQUIRE_LOCK_ERR,
> () -> kvView.put(null, Tuple.create().set("key", 9),
> Tuple.create().set("valInt", 9).set("valStr", "New_9")),
> "Failed to acquire a lock due to a possible deadlock"); {code}
> [TC
> link|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8963724]
> Reproduced locally 1/10.
>
> or sometimes with
> {code:java}
> org.opentest4j.AssertionFailedError: expected: <3> but was: <0> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.testScanWithUpperBound(ItTableScanTest.java:656)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24491) Incorrect zone replica stop order
[
https://issues.apache.org/jira/browse/IGNITE-24491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24491:
-
Epic Link: IGNITE-22115
> Incorrect zone replica stop order
> -
>
> Key: IGNITE-24491
> URL: https://issues.apache.org/jira/browse/IGNITE-24491
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In the colocation track, on node stop, zone-wide replica stop happens in the
> following steps:
> # {{ReplicaManager}} calls {{Replica#shutdown}};
> # {{ZonePartitionReplicaImpl#shutdown}} closes the zone-partition TX storage;
> # {{ReplicaManager}} stops the Raft node.
> This is a problem, because Raft may also need to access the TX storage. The
> correct order is "stop replica -> stop raft -> stop TX storage".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24928) Validate that node finder type is correct
[ https://issues.apache.org/jira/browse/IGNITE-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938834#comment-17938834 ] Kirill Tkalenko commented on IGNITE-24928: -- Looks good. > Validate that node finder type is correct > - > > Key: IGNITE-24928 > URL: https://issues.apache.org/jira/browse/IGNITE-24928 > Project: Ignite > Issue Type: Improvement >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > OneOf validation should be added for nodeFinder.type -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24940) Dealing with a log message about a failed page write at a checkpoint
Kirill Tkalenko created IGNITE-24940: Summary: Dealing with a log message about a failed page write at a checkpoint Key: IGNITE-24940 URL: https://issues.apache.org/jira/browse/IGNITE-24940 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko It found that the logs can sometimes contains the message "Checkpoint pages were not written yet due to unsuccessful page write lock acquisition and will be retried [pageCount=1]" quite often. This can be a bit disturbing for users, we need to reduce the interval for print such messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24822) Persist last created Raft snapshot information
[
https://issues.apache.org/jira/browse/IGNITE-24822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24822:
-
Epic Link: IGNITE-22115
> Persist last created Raft snapshot information
> --
>
> Key: IGNITE-24822
> URL: https://issues.apache.org/jira/browse/IGNITE-24822
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently partition Raft snapshots are represented as the current persistent
> state of the partition storages. It is proposed to separately save
> information about the last successfully performed Raft snapshot. In other
> words, when JRaft invokes {{RaftGroupListener#onSnapshotSave}} we should save
> the snapshot meta of this snapshot in the TX storage.
> This is needed as a part of the implementation of the algorithm described in
> IGNITE-24811.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24847) Move U to ignite-commons
[ https://issues.apache.org/jira/browse/IGNITE-24847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reassigned IGNITE-24847: -- Assignee: Ilya Shishkov > Move U to ignite-commons > > > Key: IGNITE-24847 > URL: https://issues.apache.org/jira/browse/IGNITE-24847 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Ilya Shishkov >Priority: Major > Labels: IEP-119, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24941) IgniteUtils initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-24941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-24941: --- Description: It is necessary to cleanup code and remove unused class members. > IgniteUtils initial cleanup > --- > > Key: IGNITE-24941 > URL: https://issues.apache.org/jira/browse/IGNITE-24941 > Project: Ignite > Issue Type: Sub-task >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Major > Labels: IEP-119, ise > > It is necessary to cleanup code and remove unused class members. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24941) IgniteUtils initial cleanup
Ilya Shishkov created IGNITE-24941: -- Summary: IgniteUtils initial cleanup Key: IGNITE-24941 URL: https://issues.apache.org/jira/browse/IGNITE-24941 Project: Ignite Issue Type: Sub-task Reporter: Ilya Shishkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24232) Implement correct node restart behaviour when forced pending
[ https://issues.apache.org/jira/browse/IGNITE-24232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-24232: - Epic Link: IGNITE-22115 > Implement correct node restart behaviour when forced pending > > > Key: IGNITE-24232 > URL: https://issues.apache.org/jira/browse/IGNITE-24232 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. Motivation > In https://issues.apache.org/jira/browse/IGNITE-23780 we have improved > correct node behaviour when node restarts according to > stable/pending(forced/not forced) keys. Several places in the code where we > start partitions where improved. > The same improvements must be done based on collocation > stable/pending(forced/not forced) keys, where zones partitions are started. > Details could be found in the original ticket > https://issues.apache.org/jira/browse/IGNITE-23780 > h3. Definition of Done > * All changes from https://issues.apache.org/jira/browse/IGNITE-23780 in the > partition restart flow must be adopted for the colocation rebalance flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24338) Support HA trigger for the Colocation track
[
https://issues.apache.org/jira/browse/IGNITE-24338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24338:
-
Epic Link: IGNITE-22115
> Support HA trigger for the Colocation track
>
>
> Key: IGNITE-24338
> URL: https://issues.apache.org/jira/browse/IGNITE-24338
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Entry point for the HA zones majority lost mechanism is
> {{DisasterRecoveryManager#onHaZoneTopologyReduce}}. We need to support this
> mechanism for the Colocation track.
> h3. Implementation notes
> From the development part, the task does not look like challenging one, once
> we implement proper {{resetPartitions}} method for zones partitions
> (https://issues.apache.org/jira/browse/IGNITE-24332), we could implement
> similar to {{DisasterRecoveryManager#onHaZoneTopologyReduce}} method but call
> correct zones' {{resetPartitions}} without selecting tables from zone.
> h3. Definition of done
> * Force reset of zones partition is scheduled, so HA triggers are handled
> properly in the collocation track
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on sesion closing with SSL enabled..
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Summary: Node failure with java.nio.channels.CancelledKeyException on
sesion closing with SSL enabled.. (was: Node failure with
java.nio.channels.CancelledKeyException on NIO SelectionKey closing.)
> Node failure with java.nio.channels.CancelledKeyException on sesion closing
> with SSL enabled..
> --
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24144) Implement a method to receive a chain of topology changes for the colocation case
[
https://issues.apache.org/jira/browse/IGNITE-24144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24144:
-
Epic Link: IGNITE-22115
> Implement a method to receive a chain of topology changes for the colocation
> case
> -
>
> Key: IGNITE-24144
> URL: https://issues.apache.org/jira/browse/IGNITE-24144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> For the purposes of HA phase 2, we have implemented the method to receive the
> chain of topology changes https://issues.apache.org/jira/browse/IGNITE-23870.
> New rebalance key was implemented, which is updated when stable switch
> happens.
> For the purposes of colocation, to create a separate set of ms rebalances
> keys, we have created a copy of all stable/pending... keys in
> {{ZoneRebalanceUtil}}. We need to create a copy for the purposes of the
> chain of topology changes method. Also this key must be updated on colocation
> stable switch as well.
> h3. Definition of done
> * Method to receive the chain of topology changes must work on the colocation
> rebalance flow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24947) Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
[
https://issues.apache.org/jira/browse/IGNITE-24947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24947:
--
Description:
{code:sql}
SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range in
'0001-00-01' (correct)
SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
{code}
This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
For literal value exception is thrown.
{code:sql}
SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in format
'-MM-dd'
{code}
Not exact, but looks acceptable.
was:
{code:sql}
SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range in
'0001-00-01'
SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
{code}
This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
For literal value exception is thrown.
{code:sql}
SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in format
'-MM-dd'
{code}
Not exact, but looks acceptable.
> Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
>
>
> Key: IGNITE-24947
> URL: https://issues.apache.org/jira/browse/IGNITE-24947
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {code:sql}
> SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range
> in '0001-00-01' (correct)
> SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
> {code}
> This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
> For literal value exception is thrown.
> {code:sql}
> SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in
> format '-MM-dd'
> {code}
> Not exact, but looks acceptable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24940) Dealing with a log message about a failed page write at a checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-24940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-24940: Assignee: Kirill Tkalenko > Dealing with a log message about a failed page write at a checkpoint > > > Key: IGNITE-24940 > URL: https://issues.apache.org/jira/browse/IGNITE-24940 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > It found that the logs can sometimes contains the message "Checkpoint pages > were not written yet due to unsuccessful page write lock acquisition and will > be retried [pageCount=1]" quite often. > This can be a bit disturbing for users, we need to reduce the interval for > print such messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24754) Calcite. TPC-H query #17: possible require too much heap memory on client
[ https://issues.apache.org/jira/browse/IGNITE-24754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-24754: - Assignee: Vladimir Steshin > Calcite. TPC-H query #17: possible require too much heap memory on client > - > > Key: IGNITE-24754 > URL: https://issues.apache.org/jira/browse/IGNITE-24754 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Korotkov >Assignee: Vladimir Steshin >Priority: Major > Labels: ise, tpch > > In scale=1.0 require a lot of heap memory on client. > In load test with 1 client and 3 servers with 5Gb heap invokes fullGC on > client side having ~17Gb totally allocated for a single query > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24894) Calcite. TPC-H query #17: incorrectly returns NULL as a result for scale=0.01
[
https://issues.apache.org/jira/browse/IGNITE-24894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-24894:
-
Description:
For scale=0.01 query #17 returns a single row (which is correct) but it
contains NULL value.
For scales 0.1 and 1.0 returns non-null value.
was:{color:#de350b}WIP{color}
> Calcite. TPC-H query #17: incorrectly returns NULL as a result for scale=0.01
> -
>
> Key: IGNITE-24894
> URL: https://issues.apache.org/jira/browse/IGNITE-24894
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Attachments: TpchQ17Test.java
>
>
> For scale=0.01 query #17 returns a single row (which is correct) but it
> contains NULL value.
> For scales 0.1 and 1.0 returns non-null value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24330) Revise DisasterRecoveryManager API in alignment with Colocation track
[
https://issues.apache.org/jira/browse/IGNITE-24330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24330:
-
Epic Link: IGNITE-22115
> Revise DisasterRecoveryManager API in alignment with Colocation track
> -
>
> Key: IGNITE-24330
> URL: https://issues.apache.org/jira/browse/IGNITE-24330
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In [collocation|https://ggsystems.atlassian.net/issues/IGN-24435] track we
> change the way how partitions are aligned with tables, so partitions will be
> the part of zones and tables in one zone will share common partitions from a
> zone.
> Currently, the DisasterRecoveryManager API for reset/restart partition
> operations is based on the assumption that partitions are tied to table
> entities.
> Example of {{resetPartitions}} method description:
> {code:java}
> * @param zoneName Name of the distribution zone. Case-sensitive, without
> quotes.
> * @param schemaName Schema name. Case-sensitive, without quotes.
> * @param tableName Table name. Case-sensitive, without quotes.
> * @param partitionIds IDs of partitions to reset. If empty, reset all
> zone's partitions.
>
> */
> private CompletableFuture resetPartitions(
> String zoneName,
> String schemaName,
> String tableName,
> Set partitionIds,
> ...
> ) {
> {code}
> Problems with the current API:
> * The current API assumes partitions are part of a specific table, making it
> unclear how to handle partition resets in the new colocation model.
> * Users don't want to affect partition distribution across all tables in a
> zone when specifying a reset for a particular table.
>
> We need to provide a way to use the DisasterRecoveryManager API in a way that
> reflects the new colocation model, where partitions belong to zones rather
> than being tied to individual tables.
> As a solution, we could introduce a revised DisasterRecoveryManagerV2 API
> that removes direct table references and operates at the zone level. Once the
> colocation track is completed, we can switch to DisasterRecoveryManagerV2 and
> deprecate the existing implementation. However, it is still unclear which
> methods will be required and how they will impact table distribution.
> h3. Definition of Done
> * DisasterRecoveryManager API is enriched with the methods to work with zones
> partitions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on session close with SSL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Summary: Node failure with java.nio.channels.CancelledKeyException on
session close with SSL enabled. (was: Node failure with
java.nio.channels.CancelledKeyException on sesion closing with SSL enabled..)
> Node failure with java.nio.channels.CancelledKeyException on session close
> with SSL enabled.
>
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-24737) Hide Sensitive Data in H2 MERGE Warning Messages
[ https://issues.apache.org/jira/browse/IGNITE-24737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev resolved IGNITE-24737. -- Resolution: Duplicate > Hide Sensitive Data in H2 MERGE Warning Messages > > > Key: IGNITE-24737 > URL: https://issues.apache.org/jira/browse/IGNITE-24737 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Priority: Major > Labels: ise > Attachments: reproducer.txt > > > In the "search by explicit key" warning messages (for MERGE queries run on > the H2 engine) sensitive query data is printed to the log regardless of the > IGNITE_TO_STRING_INCLUDE_SENSITIVE system property. > Reproducer: [^reproducer.txt] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-23167) Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge
[ https://issues.apache.org/jira/browse/IGNITE-23167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev reopened IGNITE-23167: -- Assignee: Nikita Amelchev (was: YuJue Li) > Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge > - > > Key: IGNITE-23167 > URL: https://issues.apache.org/jira/browse/IGNITE-23167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.16 >Reporter: YuJue Li >Assignee: Nikita Amelchev >Priority: Minor > Fix For: 2.16 > > Attachments: image-2024-09-09-14-55-13-666.png > > Time Spent: 1h > Remaining Estimate: 0h > > !image-2024-09-09-14-55-13-666.png! > This warning log is redundant. > When executing a MERGE statement for the first time, this warning log is > always output, which causes inconvenience to the user. However, this warning > is of no use and can be completely deleted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24757) Calcite. TPC-H query #21: failed to plan query
[
https://issues.apache.org/jira/browse/IGNITE-24757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938965#comment-17938965
]
Vladimir Steshin commented on IGNITE-24757:
---
However, the query is long. It's the long-join-reordering problem. Should be
wixed with IGNITE-24884 or IGNITE-24624. Workaround: /*+ ENFORCE_JOIN_ORDER */
> Calcite. TPC-H query #21: failed to plan query
> --
>
> Key: IGNITE-24757
> URL: https://issues.apache.org/jira/browse/IGNITE-24757
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise, tpch
>
> Sometimes fails in planning for scale=0.01
> Looks like works now for scale=0.1 and 1.0 after one of the fixes
> IGNITE-24666 and IGNITE-24688. Before it didn't complete in 10 minutes.
> {noformat}
> [2025-03-21T17:58:42,716][WARN ][test-runner-#494%tpch.TpchQ21Test%][task]
> Volcano planning times out, cancels the subsequent optimization.
> [2025-03-21T17:58:42,726][ERROR][test-runner-#494%tpch.TpchQ21Test%][PrepareServiceImpl]
> Unexpected error at query optimizer.
> org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are not
> enough rules to produce a node with desired properties: convention=IGNITE,
> sort=[1 DESC-nulls-last, 0 ASC-nulls-first], distr=single,
> rewindability=one-way, correlation=uncorrelated.
> Missing conversions are LogicalAggregate[convention: NONE -> IGNITE,
> rewindability: one-way -> rewindable] (2 cases), LogicalAggregate[convention:
> NONE -> IGNITE, distr: any -> single, rewindability: one-way -> rewindable]
> (2 cases)
> There are 4 empty subsets:
> Empty subset 0:
> rel#486:RelSubset#10.IGNITE.[].any.rewindable.correlated[$cor4], the relevant
> part of the original plan is as follows
> 261:LogicalAggregate(group=[{0}])
>
> 259:LogicalProject(subset=[rel#260:RelSubset#9.NONE.[].any.one-way.uncorrelated],
> i=[true])
>
> 257:LogicalFilter(subset=[rel#258:RelSubset#8.NONE.[].any.one-way.uncorrelated],
> condition=[AND(=($0, $cor4.L_ORDERKEY), <>($1, $cor4.L_SUPPKEY))])
>
> 239:IgniteLogicalTableScan(subset=[rel#256:RelSubset#7.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4}])
> Empty subset 1:
> rel#490:RelSubset#10.IGNITE.[].single.rewindable.correlated[$cor4], the
> relevant part of the original plan is as follows
> 261:LogicalAggregate(group=[{0}])
>
> 259:LogicalProject(subset=[rel#260:RelSubset#9.NONE.[].any.one-way.uncorrelated],
> i=[true])
>
> 257:LogicalFilter(subset=[rel#258:RelSubset#8.NONE.[].any.one-way.uncorrelated],
> condition=[AND(=($0, $cor4.L_ORDERKEY), <>($1, $cor4.L_SUPPKEY))])
>
> 239:IgniteLogicalTableScan(subset=[rel#256:RelSubset#7.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4}])
> Empty subset 2:
> rel#478:RelSubset#15.IGNITE.[].any.rewindable.correlated[$cor0], the relevant
> part of the original plan is as follows
> 270:LogicalAggregate(group=[{0}])
>
> 268:LogicalProject(subset=[rel#269:RelSubset#14.NONE.[].any.one-way.uncorrelated],
> i=[true])
>
> 266:LogicalFilter(subset=[rel#267:RelSubset#13.NONE.[].any.one-way.uncorrelated],
> condition=[AND(=($0, $cor0.L_ORDERKEY), <>($1, $cor0.L_SUPPKEY), >($3, $2))])
>
> 241:IgniteLogicalTableScan(subset=[rel#265:RelSubset#12.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4, 13, 14}])
> Empty subset 3:
> rel#483:RelSubset#15.IGNITE.[].single.rewindable.correlated[$cor0], the
> relevant part of the original plan is as follows
> 270:LogicalAggregate(group=[{0}])
>
> 268:LogicalProject(subset=[rel#269:RelSubset#14.NONE.[].any.one-way.uncorrelated],
> i=[true])
>
> 266:LogicalFilter(subset=[rel#267:RelSubset#13.NONE.[].any.one-way.uncorrelated],
> condition=[AND(=($0, $cor0.L_ORDERKEY), <>($1, $cor0.L_SUPPKEY), >($3, $2))])
>
> 241:IgniteLogicalTableScan(subset=[rel#265:RelSubset#12.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4, 13, 14}])
> Root: rel#284:RelSubset#21.IGNITE.[1 DESC-nulls-last, 0
> ASC-nulls-first].single.one-way.uncorrelated
> Original rel:
> LogicalSort(subset=[rel#284:RelSubset#21.IGNITE.[1 DESC-nulls-last, 0
> ASC-nulls-first].single.one-way.uncorrelated], sort0=[$1], sort1=[$0],
> dir0=[DESC-nulls-last], dir1=[ASC-nulls-first], fetch=[100]): rowcount =
> 2.7267694333560168E13, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 282
>
> LogicalAggregate(subset=[rel#281:RelSubset#20.NONE.[].any.one-way.uncorrelated],
> group=[{0}], NUMWAIT=[COUNT()]): rowcount = 2.7267694333560168E13,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Inf
[jira] [Updated] (IGNITE-23919) Remove DurableBackgroundCleanupIndexTreeTask and related code
[ https://issues.apache.org/jira/browse/IGNITE-23919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-23919: --- Fix Version/s: 2.18 > Remove DurableBackgroundCleanupIndexTreeTask and related code > - > > Key: IGNITE-23919 > URL: https://issues.apache.org/jira/browse/IGNITE-23919 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Ilya Shishkov >Priority: Major > Labels: IEP-132, IEP-80, ise > Fix For: 2.18 > > Time Spent: 40m > Remaining Estimate: 0h > > DurableBackgroundCleanupIndexTreeTask deprecated and can be removed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Description:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}}).
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
was:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}} returns silently {{2006-07-14}})
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
> 'DD-MM-YY')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24947) Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
Pavel Pereslegin created IGNITE-24947:
-
Summary: Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with
zero DAY value
Key: IGNITE-24947
URL: https://issues.apache.org/jira/browse/IGNITE-24947
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
{code:sql}
SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range in
'0001-00-01'
SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
{code}
This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
For literal value exception is thrown.
{code:sql}
SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in format
'-MM-dd'
{code}
Not exact, but looks acceptable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24947) Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
[
https://issues.apache.org/jira/browse/IGNITE-24947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24947:
--
Description:
{code:sql}
SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range in
'0001-00-01' (correct)
SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
SELECT '0001-01-32'::DATE -- Throws: Value of DAY field is out of range in
'0001-01-32' (correct)
{code}
This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
For literal value exception is thrown.
{code:sql}
SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in format
'-MM-dd'
{code}
Looks acceptable.
was:
{code:sql}
SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range in
'0001-00-01' (correct)
SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
{code}
This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
For literal value exception is thrown.
{code:sql}
SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in format
'-MM-dd'
{code}
Not exact, but looks acceptable.
> Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
>
>
> Key: IGNITE-24947
> URL: https://issues.apache.org/jira/browse/IGNITE-24947
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {code:sql}
> SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range
> in '0001-00-01' (correct)
> SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
> SELECT '0001-01-32'::DATE -- Throws: Value of DAY field is out of range in
> '0001-01-32' (correct)
> {code}
> This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
> For literal value exception is thrown.
> {code:sql}
> SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in
> format '-MM-dd'
> {code}
> Looks acceptable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24746) Calcite. TPC-H query #8: failed to plan query
[
https://issues.apache.org/jira/browse/IGNITE-24746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938969#comment-17938969
]
Vladimir Steshin commented on IGNITE-24746:
---
It's the long-join-reordering problem. Should be wixed with IGNITE-24884 or
IGNITE-24624. Workaround: /*+ ENFORCE_JOIN_ORDER */
> Calcite. TPC-H query #8: failed to plan query
> -
>
> Key: IGNITE-24746
> URL: https://issues.apache.org/jira/browse/IGNITE-24746
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise, tpch
> Attachments: TpchQ8Test.java
>
>
> Query worked (but very slowly) before the IGNITE-24642. Now always fails in
> planning.
> ***
> Very similar to query #5 problem (IGNITE-24741) but fails always for me.
>
> {noformat}
> [2025-03-18T17:00:52,636][WARN ][test-runner-#494%tpch.TpchQ8Test%][task]
> Volcano planning times out, cancels the subsequent optimization.
> [2025-03-18T17:00:52,638][ERROR][test-runner-#494%tpch.TpchQ8Test%][PrepareServiceImpl]
> Unexpected error at query optimizer.
> org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are not
> enough rules to produce a node with desired properties: convention=IGNITE,
> sort=[0 ASC-nulls-first], distr=single, rewindability=one-way,
> correlation=uncorrelated.
> Missing conversions are IgniteLogicalTableScan[convention: NONE -> IGNITE,
> sort: [] -> [0], distr: any -> single], IgniteLogicalTableScan[convention:
> NONE -> IGNITE, sort: [] -> [0]]
> There are 2 empty subsets:
> Empty subset 0: rel#4770:RelSubset#11.IGNITE.[0].any.one-way.uncorrelated,
> the relevant part of the original plan is as follows
> 413:IgniteLogicalTableScan(table=[[PUBLIC, NATION]], requiredColumns=[{2, 3}])
> Empty subset 1: rel#4775:RelSubset#11.IGNITE.[0].single.one-way.uncorrelated,
> the relevant part of the original plan is as follows
> 413:IgniteLogicalTableScan(table=[[PUBLIC, NATION]], requiredColumns=[{2, 3}])
> Root: rel#4748:RelSubset#17.IGNITE.[0
> ASC-nulls-first].single.one-way.uncorrelated
> Original rel:
> LogicalSort(subset=[rel#461:RelSubset#18.IGNITE.[0
> ASC-nulls-first].single.one-way.uncorrelated], sort0=[$0],
> dir0=[ASC-nulls-first]): rowcount = 5.421865196228027E12, cumulative cost =
> IgniteCost [rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
> network=Infinity], id = 459
>
> LogicalProject(subset=[rel#458:RelSubset#17.NONE.[].any.one-way.uncorrelated],
> O_YEAR=[$0], MKT_SHARE=[/($1, $2)]): rowcount = 5.421865196228027E12,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Infinity, network=Infinity], id = 457
>
> LogicalAggregate(subset=[rel#456:RelSubset#16.NONE.[].any.one-way.uncorrelated],
> group=[{0}], agg#0=[SUM($1)], agg#1=[SUM($2)]): rowcount =
> 5.421865196228027E12, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 455
>
> LogicalProject(subset=[rel#454:RelSubset#15.NONE.[].any.one-way.uncorrelated],
> O_YEAR=[EXTRACT(FLAG(YEAR), $11)], $f1=[CASE(=($17, _UTF-8'BRAZIL'), *($7,
> -(1, $8)), 0.:DECIMAL(31, 4))], VOLUME=[*($7, -(1, $8))]): rowcount =
> 1.0843730392456055E13, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 453
>
> LogicalJoin(subset=[rel#452:RelSubset#14.NONE.[].any.one-way.uncorrelated],
> condition=[=($15, $18)], joinType=[inner]): rowcount = 1.0843730392456055E13,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Infinity, network=Infinity], id = 451
>
> LogicalJoin(subset=[rel#449:RelSubset#12.NONE.[].any.one-way.uncorrelated],
> condition=[=($3, $16)], joinType=[inner]): rowcount = 7.229153594970703E13,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Infinity, network=Infinity], id = 448
>
> LogicalJoin(subset=[rel#446:RelSubset#10.NONE.[].any.one-way.uncorrelated],
> condition=[=($13, $14)], joinType=[inner]): rowcount = 1.9277742919921875E13,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Infinity, network=Infinity], id = 445
>
> LogicalJoin(subset=[rel#443:RelSubset#8.NONE.[].any.one-way.uncorrelated],
> condition=[=($10, $12)], joinType=[inner]): rowcount = 5.1407314453125E12,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memory=Infinity, io=Infinity, network=Infinity], id = 442
>
> LogicalJoin(subset=[rel#440:RelSubset#6.NONE.[].any.one-way.uncorrelated],
> condition=[=($4, $9)], joinType=[inner]): rowcount = 2.28476953125E10,
> cumulative cost = IgniteCost [rowCount=Infinity, cpu=Infinity,
> memor
[jira] [Resolved] (IGNITE-24885) ItSqlClientAsynchronousApiTest#ddl hangs in case of enabled colocation
[
https://issues.apache.org/jira/browse/IGNITE-24885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy resolved IGNITE-24885.
Fix Version/s: 3.1
Resolution: Fixed
Fixed by IGNITE-24938
> ItSqlClientAsynchronousApiTest#ddl hangs in case of enabled colocation
> --
>
> Key: IGNITE-24885
> URL: https://issues.apache.org/jira/browse/IGNITE-24885
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> Aforementioned test hangs on index creation
> {code:java}
> checkDdl(true, sql, "CREATE INDEX TEST_IDX ON TEST(VAL0)"); {code}
> with following exceptions in logs
> {code:java}
> [2025-03-20T12:48:39,565][INFO
> ][%iscaat_n_3344%metastorage-watch-executor-2][IndexManager] Creating local
> index: name=TEST_IDX, id=20, tableId=18, token=346
> [2025-03-20T12:48:39,574][WARN
> ][%iscaat_n_3344%JRaft-FSMCaller-Disruptor-metastorage_stripe_0-0][CatalogManagerImpl]
> Failed to apply catalog update.
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.storage.StorageException: IGN-CMN-65535
> TraceId:6031ffc5-97f0-41c0-8b72-8021fde8d293 Partition ID 8 does not exist
> {code}
> Same for ItSqlApiBaseTest#checkMixedTransactionsForIndex
> {code:java}
> [2025-03-20T13:23:42,934][INFO
> ][%isaat_n_3344%metastorage-watch-executor-2][IndexManager] Creating local
> index: name=TEST_IDX, id=20, tableId=18, token=338
> [2025-03-20T13:23:42,941][WARN
> ][%isaat_n_3344%JRaft-FSMCaller-Disruptor-metastorage_stripe_0-0][CatalogManagerImpl]
> Failed to apply catalog update.
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.storage.StorageException: IGN-CMN-65535
> TraceId:3b285cf2-2e13-42f3-bccc-32e451f47751 Partition ID 5 does not exist
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Affects Version/s: 3.0
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24947) Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
[
https://issues.apache.org/jira/browse/IGNITE-24947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24947:
--
Affects Version/s: 3.0
> Sql. Add validation for cast VARCHAR::DATE/TIMESTAMP with zero DAY value
>
>
> Key: IGNITE-24947
> URL: https://issues.apache.org/jira/browse/IGNITE-24947
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {code:sql}
> SELECT '0001-00-01'::DATE -- Throws: Value of MONTH field is out of range
> in '0001-00-01' (correct)
> SELECT '0001-01-00'::DATE -- produces invalid result [-12-31]
> SELECT '0001-01-32'::DATE -- Throws: Value of DAY field is out of range in
> '0001-01-32' (correct)
> {code}
> This affects TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE also.
> For literal value exception is thrown.
> {code:sql}
> SELECT date '0001-01-00' -- Illegal DATE literal '0001-01-00': not in
> format '-MM-dd'
> {code}
> Looks acceptable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24949) Refactor in createTableLocally
Philipp Shergalis created IGNITE-24949: -- Summary: Refactor in createTableLocally Key: IGNITE-24949 URL: https://issues.apache.org/jira/browse/IGNITE-24949 Project: Ignite Issue Type: Improvement Reporter: Philipp Shergalis Assignee: Philipp Shergalis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938956#comment-17938956
]
Pavel Pereslegin edited comment on IGNITE-24909 at 3/27/25 3:14 PM:
Calcite uses SimpleDateFormat to parse dates internally (see
{{org.apache.calcite.runtime.SqlFunctions.DateParseFunction.Key#toDateFormat}}),
so issues with possible invalid/wrong patterns and overflows are caused by
Java's SimpleDateFormat usage without additional validations.
For example the following is acceptable for SimpleDateFormat:
{code:java}
DateFormat df = new SimpleDateFormat("yy-MM-dd", Locale.ENGLISH);
System.out.println(df.parse("999-999-999")); // Sun Dec 27
00:00:00 MSK 998
{code}
And the same is acceptable by Calcite
{code:java}
sql("SELECT CAST('999-999-999' AS DATE FORMAT 'yy-MM-dd')"); //
[[-898510-03-05]]
{code}
was (Author: xtern):
Calcite uses SimpleDateFormat to parse dates internally, so issues with
possible invalid/wrong patterns and overflows are caused by Java's
SimpleDateFormat usage without additional validations.
For example the following is acceptable for SimpleDateFormat:
{code:java}
DateFormat df = new SimpleDateFormat("yy-MM-dd", Locale.ENGLISH);
System.out.println(df.parse("999-999-999")); // Sun Dec 27
00:00:00 MSK 998
{code}
And the same is acceptable by Calcite
{code:java}
sql("SELECT CAST('999-999-999' AS DATE FORMAT 'yy-MM-dd')"); //
[[-898510-03-05]]
{code}
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-24853) Review the use of the Metastorage safe time tracker
[ https://issues.apache.org/jira/browse/IGNITE-24853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-24853. -- Resolution: Not A Problem I looked at the usage, at the moment it doesn't look like the safe time tracker is very busy. > Review the use of the Metastorage safe time tracker > --- > > Key: IGNITE-24853 > URL: https://issues.apache.org/jira/browse/IGNITE-24853 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > We need to make sure that when using the metastorage safe time tracker we do > not do long/load operations. If there is such a thing, we will need to create > separate requests and handle it individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24939) Improve troubleshooting documentation section.
[
https://issues.apache.org/jira/browse/IGNITE-24939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-24939:
--
Description:
Ignite 2 requires Java 11 or later version to start.
Since Java 9, some JVM options were deprecated and then removed [1], but we
still use them in our documentation [2].
Let's fix documentation and replace outdated JVM options with new ones using
the guide [3]
{code:java}
Old: -XX:+PrintGCDetails
New: -Xlog:gc*
Old: -Xloggc:
New: -Xlog:gc:
Old: -XX:+PrintGCTimeStamps
New: Not Applicable. Time stamps are logged by the framework.
Old: -XX:+PrintGCDateStamps
New: Not Applicable. Date stamps are logged by the framework.
{code}
[1] https://bugs.openjdk.org/browse/JDK-8145180
[2]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
[3]
https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1
was:
Ignite 2 requires Java 11 or later version to start.
Since Java 9, some JVM options were deprecated and then removed [1], but we
still use them in our documentation [2].
Let's fix documentation and replace outdated JVM options with new ones.
{code:java}
Old: -XX:+PrintGCDetails
New: -Xlog:gc*
Old: -Xloggc:
New: -Xlog:gc:
{code}
[1] https://bugs.openjdk.org/browse/JDK-8145180
[2]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
> Improve troubleshooting documentation section.
> --
>
> Key: IGNITE-24939
> URL: https://issues.apache.org/jira/browse/IGNITE-24939
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-2
>
> Ignite 2 requires Java 11 or later version to start.
> Since Java 9, some JVM options were deprecated and then removed [1], but we
> still use them in our documentation [2].
> Let's fix documentation and replace outdated JVM options with new ones using
> the guide [3]
> {code:java}
> Old: -XX:+PrintGCDetails
> New: -Xlog:gc*
> Old: -Xloggc:
> New: -Xlog:gc:
> Old: -XX:+PrintGCTimeStamps
> New: Not Applicable. Time stamps are logged by the framework.
> Old: -XX:+PrintGCDateStamps
> New: Not Applicable. Date stamps are logged by the framework.
> {code}
> [1] https://bugs.openjdk.org/browse/JDK-8145180
> [2]
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting#detailed-gc-logs
> [3]
> https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on session close with SSL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Node failure with java.nio.channels.CancelledKeyException on session close
> with SSL enabled.
>
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on session close with SSL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Fix Version/s: 2.18
> Node failure with java.nio.channels.CancelledKeyException on session close
> with SSL enabled.
>
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.18
>
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on session close with SSL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Labels: ise (was: )
> Node failure with java.nio.channels.CancelledKeyException on session close
> with SSL enabled.
>
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
> Labels: ise
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24913) Fix falky TcpCommunicationSpiSslVolatilePayloadTest
[ https://issues.apache.org/jira/browse/IGNITE-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17939067#comment-17939067 ] Mikhail Petrov commented on IGNITE-24913: - [~NSAmelchev] Thank you for the review. > Fix falky TcpCommunicationSpiSslVolatilePayloadTest > --- > > Key: IGNITE-24913 > URL: https://issues.apache.org/jira/browse/IGNITE-24913 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.18 > > Time Spent: 1.5h > Remaining Estimate: 0h > > See > https://ci2.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=4077873124689907116&page=1&branch_IgniteTests24Java8=%3Cdefault%3E > for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24913) Fix falky TcpCommunicationSpiSslVolatilePayloadTest
[ https://issues.apache.org/jira/browse/IGNITE-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-24913: Labels: ise (was: ) > Fix falky TcpCommunicationSpiSslVolatilePayloadTest > --- > > Key: IGNITE-24913 > URL: https://issues.apache.org/jira/browse/IGNITE-24913 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.18 > > Time Spent: 1.5h > Remaining Estimate: 0h > > See > https://ci2.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=4077873124689907116&page=1&branch_IgniteTests24Java8=%3Cdefault%3E > for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24335) Support DisasterRecoveryManager#restartPartition in Colocation track
[
https://issues.apache.org/jira/browse/IGNITE-24335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24335:
-
Epic Link: IGNITE-22115
> Support DisasterRecoveryManager#restartPartition in Colocation track
>
>
> Key: IGNITE-24335
> URL: https://issues.apache.org/jira/browse/IGNITE-24335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> This ticket is a part of the implementation track for
> https://issues.apache.org/jira/browse/IGNITE-24330, where we have revised
> DisasterRecoveryManager API in alignment with Colocation track
> In this ticket we have to provide a correct behaviour for
> {{DisasterRecoveryManager#restartPartition}} for partitions from zones.
> h3. Implementation notes
> As usual for the such methods from DisasterRecoveryManager, we must switch to
> {{ZonePartitionId}}. Also this mechanism uses under the hood
> {{TableManager#restartPartition}}. Seems that we need to have similar method
> in {{PartitionReplicaLifecycleManager}}, which has all prerequisites like
> {{PartitionReplicaLifecycleManager#weakStopPartition}},
> {{PartitionReplicaLifecycleManager#waitForMetadataCompleteness}}
> h3. Definition of Done
> * DisasterRecoveryManager API is enriched with {{restartPartition}} method
> that works with zones' based partitions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24230) Enrich Disaster Recovery REST API with new methods for the colocation case
[
https://issues.apache.org/jira/browse/IGNITE-24230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24230:
-
Epic Link: IGNITE-22115
> Enrich Disaster Recovery REST API with new methods for the colocation case
> --
>
> Key: IGNITE-24230
> URL: https://issues.apache.org/jira/browse/IGNITE-24230
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Once we revise DisasterRecoveryManager API in alignment with Colocation track
> https://issues.apache.org/jira/browse/IGNITE-24330 and implement all related
> tickets, so DisasterRecoveryManager API is improved with new methods that
> work with zones' partitions,
> we need to implement REST API for all new methods. See
> {{DisasterRecoveryController}}
> h3. Definition of done
> * REST API of DisasterRecoveryManager is improved with new methods that were
> implemented for zones' partitions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24741) Calcite. TPC-H query #5: failed to plan query
[
https://issues.apache.org/jira/browse/IGNITE-24741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938962#comment-17938962
]
Vladimir Steshin commented on IGNITE-24741:
---
The test seems to pass. At least on my laptop. However, the query is long. It's
the long-join-reordering problem. Should be wixed with IGNITE-24884 or
IGNITE-24624. Workaround: /*+ ENFORCE_JOIN_ORDER */
> Calcite. TPC-H query #5: failed to plan query
> -
>
> Key: IGNITE-24741
> URL: https://issues.apache.org/jira/browse/IGNITE-24741
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise, tpch
> Attachments: TpchQ5Test.java, TpchQ5Test.log
>
>
> Sometimes produce error during planning in the attached test. See the log.
> {noformat}
> Suppressed: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=IGNITE, sort=[1 DESC-nulls-last], distr=single,
> rewindability=one-way, correlation=uncorrelated.
> Missing conversions are LogicalJoin[convention: NONE -> IGNITE, sort: [] ->
> [6, 1], distr: any -> single], LogicalJoin[convention: NONE -> IGNITE, sort:
> [] -> [6, 1]]
> There are 2 empty subsets:
> Empty subset 0: rel#2055:RelSubset#4.IGNITE.[6, 1].any.one-way.uncorrelated,
> the relevant part of the original plan is as follows
> 335:LogicalJoin(condition=[=($5, $2)], joinType=[inner])
>
> 332:LogicalJoin(subset=[rel#333:RelSubset#2.NONE.[].any.one-way.uncorrelated],
> condition=[=($0, $3)], joinType=[inner])
>
> 288:IgniteLogicalTableScan(subset=[rel#330:RelSubset#0.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, CUSTOMER]], requiredColumns=[{2, 5}])
>
> 295:IgniteLogicalTableScan(subset=[rel#331:RelSubset#1.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, ORDERS]], filters=[AND(>=($t2, 1994-01-01), <($t2,
> +(1994-01-01, *(12:INTERVAL YEAR, 1], requiredColumns=[{2, 3, 6}])
>
> 302:IgniteLogicalTableScan(subset=[rel#334:RelSubset#3.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4, 7, 8}])
> Empty subset 1: rel#2060:RelSubset#4.IGNITE.[6,
> 1].single.one-way.uncorrelated, the relevant part of the original plan is as
> follows
> 335:LogicalJoin(condition=[=($5, $2)], joinType=[inner])
>
> 332:LogicalJoin(subset=[rel#333:RelSubset#2.NONE.[].any.one-way.uncorrelated],
> condition=[=($0, $3)], joinType=[inner])
>
> 288:IgniteLogicalTableScan(subset=[rel#330:RelSubset#0.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, CUSTOMER]], requiredColumns=[{2, 5}])
>
> 295:IgniteLogicalTableScan(subset=[rel#331:RelSubset#1.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, ORDERS]], filters=[AND(>=($t2, 1994-01-01), <($t2,
> +(1994-01-01, *(12:INTERVAL YEAR, 1], requiredColumns=[{2, 3, 6}])
>
> 302:IgniteLogicalTableScan(subset=[rel#334:RelSubset#3.NONE.[].any.one-way.uncorrelated],
> table=[[PUBLIC, LINEITEM]], requiredColumns=[{2, 4, 7, 8}])
> {noformat}
>
> May be the reason is in this warning. It can be that cancel in random moment
> may cause the problem sometimes. Default timeout is 15 seconds and mat be
> changed via IGNITE_CALCITE_PLANNER_TIMEOUT.
> {noformat}
> [2025-03-11T13:25:38,068][WARN ][test-runner-#493%tpch.TpchQ5Test%][task]
> Volcano planning times out, cancels the subsequent optimization.
> {noformat}
> If enable the `calcite.volcano.dump.graphviz`=true and
> `calcite.volcano.dump.sets`=true (which are anabled by default) in case of
> error may produce a huge logs and hang in `VolcanoPlanner.dump` eating
> gigabytes of memory. Note in the below dump the *elapsed=570.01s
> allocated=378G*
>
> {noformat}
> "org.apache.ignite.internal.benchmarks.jmh.sql.tpch.TpchBenchmark.cold-jmh-worker-1"
> #22 daemon prio=5 os_prio=0 cpu=563001.94ms elapsed=570.01s allocated=378G
> defined_classes=115
> 93 tid=0x7ad05d7a4000 nid=0x49b7e runnable [0x7ad0116fa000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.calcite.plan.RelTraitSet.satisfies(RelTraitSet.java:496)
> at
> org.apache.calcite.plan.volcano.Dumpers.lambda$dumpGraphviz$2(Dumpers.java:183)
> at
> org.apache.calcite.plan.volcano.Dumpers$$Lambda$2624/0x000840ce7c40.lessThan(Unknown
> Source)
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParentsChildren(PartiallyOrderedSet.java:340)
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParents(PartiallyOrderedSet.java:315)
> at
> org.apache.calcite.util.PartiallyOrderedSet.add(PartiallyOrderedSet.java:233)
> at
> org.apache.calcite.plan.volcano.Dumpers.dumpGraphviz(Dumpers.java:239)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.dump(VolcanoPlanner.java:8
[jira] [Created] (IGNITE-24942) StackOverflowError in PartitionMover
Roman Puchkovskiy created IGNITE-24942: -- Summary: StackOverflowError in PartitionMover Key: IGNITE-24942 URL: https://issues.apache.org/jira/browse/IGNITE-24942 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23167) Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge
[
https://issues.apache.org/jira/browse/IGNITE-23167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17939077#comment-17939077
]
Ignite TC Bot commented on IGNITE-23167:
{panel:title=Branch: [pull/11967/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11967/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8371202&buildTypeId=IgniteTests24Java8_RunAll]
> Cleaning up redundant warning log output in GridSqlQueryParser#parseMerge
> -
>
> Key: IGNITE-23167
> URL: https://issues.apache.org/jira/browse/IGNITE-23167
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.16
>Reporter: YuJue Li
>Assignee: Nikita Amelchev
>Priority: Minor
> Labels: ise
> Fix For: 2.18
>
> Attachments: image-2024-09-09-14-55-13-666.png
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> !image-2024-09-09-14-55-13-666.png!
> This warning log is redundant.
> When executing a MERGE statement for the first time, this warning log is
> always output, which causes inconvenience to the user. However, this warning
> is of no use and can be completely deleted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24935) Switch MvTableStorage to create*Index methods
[ https://issues.apache.org/jira/browse/IGNITE-24935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24935: --- Description: MvTableStorage contains methods that either get existing index partition storage or create a new one and return the result, but # we always use them in situations where we know that we need to create a storage # we never need the returned value We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to createHashIndex() and createSortedIndex(), respectively. This will allow us to make a quick and dirty fix for IGNITE-24926. Also, getOrCreateIndex() method is not used in production code, so it should be removed. was: MvTableStorage contains methods that either get existing index partition storage or create a new one and return the result, but # we always use them in situations where we know that we need to create a storage # we never need the returned value We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to createHashIndex() and createSortedIndex(), respectively. Also, getOrCreateIndex() method is not used in production code, so it should be removed. > Switch MvTableStorage to create*Index methods > - > > Key: IGNITE-24935 > URL: https://issues.apache.org/jira/browse/IGNITE-24935 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > MvTableStorage contains methods that either get existing index partition > storage or create a new one and return the result, but > # we always use them in situations where we know that we need to create a > storage > # we never need the returned value > We should change getOrCreateHashIndex() and getOrCreateSortedIndex() to > createHashIndex() and createSortedIndex(), respectively. This will allow us > to make a quick and dirty fix for IGNITE-24926. > Also, getOrCreateIndex() method is not used in production code, so it should > be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24935) Replace getOrCreateIndexStorage methods with createIndexStorage methods
Roman Puchkovskiy created IGNITE-24935: -- Summary: Replace getOrCreateIndexStorage methods with createIndexStorage methods Key: IGNITE-24935 URL: https://issues.apache.org/jira/browse/IGNITE-24935 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24331) Support DisasterRecoveryManager#localPartitionStates and globalPartitionStates in Colocation track
[
https://issues.apache.org/jira/browse/IGNITE-24331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin reassigned IGNITE-24331:
Assignee: Kirill Sizov (was: Mirza Aliev)
> Support DisasterRecoveryManager#localPartitionStates and
> globalPartitionStates in Colocation track
> --
>
> Key: IGNITE-24331
> URL: https://issues.apache.org/jira/browse/IGNITE-24331
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> This ticket is a part of the implementation track for
> https://issues.apache.org/jira/browse/IGNITE-24330, where we have revised
> DisasterRecoveryManager API in alignment with Colocation track
> In this ticket we have to provide a correct behaviour for
> {{DisasterRecoveryManager#localPartitionStates}} and close method
> {{DisasterRecoveryManager#globalPartitionStates}} which uses
> {{localPartitionStates}}.
> Currently, those methods return a mapping of {{TablePartitionId}} to the
> mapping between a node name and a partition state.
> To conform Collocation track, those methods must use {{ZonePartitionId}} and
> hence return states of a zone's partition rather than table's.
> h3. Definition of Done
> * DisasterRecoveryManager API is enriched with {{localPartitionStates}} and
> {{globalPartitionStates}} methods that work with zones' based partitions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24928) Improve node finder configuration
[ https://issues.apache.org/jira/browse/IGNITE-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-24928: --- Description: Polymorphic configuration should be used for static / multicast config was:OneOf validation should be added for nodeFinder.type > Improve node finder configuration > - > > Key: IGNITE-24928 > URL: https://issues.apache.org/jira/browse/IGNITE-24928 > Project: Ignite > Issue Type: Improvement >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Polymorphic configuration should be used for static / multicast config > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24940) Dealing with a log message about a failed page write at a checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-24940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-24940: Assignee: (was: Kirill Tkalenko) > Dealing with a log message about a failed page write at a checkpoint > > > Key: IGNITE-24940 > URL: https://issues.apache.org/jira/browse/IGNITE-24940 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > It found that the logs can sometimes contains the message "Checkpoint pages > were not written yet due to unsuccessful page write lock acquisition and will > be retried [pageCount=1]" quite often. > This can be a bit disturbing for users, we need to reduce the interval for > print such messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24942) StackOverflowError in PartitionMover
[ https://issues.apache.org/jira/browse/IGNITE-24942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24942: --- Description: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception as a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) # Maybe we should initiate a retry in a separate thread pool to avoid stack overflow if there are many retries (or simply pick max retry count that is not big enough to trigger stack overflow) was: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception as a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) > StackOverflowError in PartitionMover > > > Key: IGNITE-24942 > URL: https://issues.apache.org/jira/browse/IGNITE-24942 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > PartitionMover makes a retry on an exception. Retries are made on each > exception (including those that are not retriable), there is no retry limit > and the retries might happen in the same thread, which sometimes leads to an > infinite loop (resulting in StackOverflowException) is something is broken. > # We need to differentiate which exceptions are retryable and which are not > # For non-retryable ones, we should call FailureManager right away and stop > retrying > # For retryable ones, we should add a retry counter and stop handling an > exception as a retryable when the counter reaches some limit (that is, stop > retrying and notify FailureManager) > # Maybe we should initiate a retry in a separate thread pool to avoid stack > overflow if there are many retries (or simply pick max retry count that is > not big enough to trigger stack overflow) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24942) StackOverflowError in PartitionMover
[ https://issues.apache.org/jira/browse/IGNITE-24942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-24942: - Description: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowError) if something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception as a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) # Maybe we should initiate a retry in a separate thread pool to avoid stack overflow if there are many retries (or simply pick max retry count that is not big enough to trigger stack overflow) was: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception as a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) # Maybe we should initiate a retry in a separate thread pool to avoid stack overflow if there are many retries (or simply pick max retry count that is not big enough to trigger stack overflow) > StackOverflowError in PartitionMover > > > Key: IGNITE-24942 > URL: https://issues.apache.org/jira/browse/IGNITE-24942 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > PartitionMover makes a retry on an exception. Retries are made on each > exception (including those that are not retriable), there is no retry limit > and the retries might happen in the same thread, which sometimes leads to an > infinite loop (resulting in StackOverflowError) if something is broken. > # We need to differentiate which exceptions are retryable and which are not > # For non-retryable ones, we should call FailureManager right away and stop > retrying > # For retryable ones, we should add a retry counter and stop handling an > exception as a retryable when the counter reaches some limit (that is, stop > retrying and notify FailureManager) > # Maybe we should initiate a retry in a separate thread pool to avoid stack > overflow if there are many retries (or simply pick max retry count that is > not big enough to trigger stack overflow) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-24854) Review the use of the partition safe time tracker
[ https://issues.apache.org/jira/browse/IGNITE-24854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-24854. -- Resolution: Not A Problem Having analyzed the usage it looks like the safe time tracker is being used without any significant issues at the moment. > Review the use of the partition safe time tracker > - > > Key: IGNITE-24854 > URL: https://issues.apache.org/jira/browse/IGNITE-24854 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > We need to make sure that when using the partition safe time tracker we do > not do long/load operations. If there is such a thing, we will need to create > separate requests and handle it individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24944) Improve TrackerClosedException handling
Roman Puchkovskiy created IGNITE-24944: -- Summary: Improve TrackerClosedException handling Key: IGNITE-24944 URL: https://issues.apache.org/jira/browse/IGNITE-24944 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24942) StackOverflowError in PartitionMover
[ https://issues.apache.org/jira/browse/IGNITE-24942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24942: --- Issue Type: Bug (was: Improvement) > StackOverflowError in PartitionMover > > > Key: IGNITE-24942 > URL: https://issues.apache.org/jira/browse/IGNITE-24942 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > PartitionMover makes a retry on an exception. Retries are made on each > exception (including those that are not retriable), there is no retry limit > and the retries might happen in the same thread, which sometimes leads to an > infinite loop (resulting in StackOverflowException) is something is broken. > # We need to differentiate which exceptions are retryable and which are not > # For non-retryable ones, we should call FailureManager right away and stop > retrying > # For retryable ones, we should add a retry counter and stop handling an > exception as a retryable when the counter reaches some limit (that is, stop > retrying and notify FailureManager) > # Maybe we should initiate a retry in a separate thread pool to avoid stack > overflow if there are many retries (or simply pick max retry count that is > not big enough to trigger stack overflow) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24944) Improve TrackerClosedException handling
[ https://issues.apache.org/jira/browse/IGNITE-24944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24944: --- Description: IndexBuildTask might get TrackerClosedException if a partition for which the index is being built got destroyed. This means that the index build have to be stopped (and this is already implemented), so the exception should be simply ignored by IndexBuildTask; it should not even be logged. ReplicaManager should also ignore TrackerClosedExceptions that are passed through it. > Improve TrackerClosedException handling > --- > > Key: IGNITE-24944 > URL: https://issues.apache.org/jira/browse/IGNITE-24944 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > IndexBuildTask might get TrackerClosedException if a partition for which the > index is being built got destroyed. This means that the index build have to > be stopped (and this is already implemented), so the exception should be > simply ignored by IndexBuildTask; it should not even be logged. > ReplicaManager should also ignore TrackerClosedExceptions that are passed > through it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24936) Sql. Allow access of virtual column "__part" without quoting
[
https://issues.apache.org/jira/browse/IGNITE-24936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-24936:
--
Summary: Sql. Allow access of virtual column "__part" without quoting
(was: Sql. Rename virtual column "__part" to allow access without quoting)
> Sql. Allow access of virtual column "__part" without quoting
>
>
> Key: IGNITE-24936
> URL: https://issues.apache.org/jira/browse/IGNITE-24936
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, column representing partition id is registered in lower case,
> which make it necessary to wrap {{__part}} in double quotes. To allow
> unquoted access, we need to register this column in upper case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Description:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}} returns silently {{2006-07-14}})
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
was:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM, and pattern
mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}} doesn't fail currently)
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
> 'DD-MM-YY')}} returns silently {{2006-07-14}})
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24938) Ignore attempts to create index storage in destroyed partition
[ https://issues.apache.org/jira/browse/IGNITE-24938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24938: --- Summary: Ignore attempts to create index storage in destroyed partition (was: Ignore attempts to create index storage in destroyed table storage) > Ignore attempts to create index storage in destroyed partition > -- > > Key: IGNITE-24938 > URL: https://issues.apache.org/jira/browse/IGNITE-24938 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > IGNITE-24926 requires a lot of time to fix. This one is a fast and dirty > workaround for it. > The only problem that the race described in IGNITE-24926 causes is that, when > creating an index storage (on index registration), we might get into a > situation when the partition storage is already destroyed due to partition > eviction initiated AFTER the index registration. The workaround is to quietly > ignore such attempts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24945) Node failure in with java.nio.channels.CancelledKeyException
Mikhail Petrov created IGNITE-24945:
---
Summary: Node failure in with
java.nio.channels.CancelledKeyException
Key: IGNITE-24945
URL: https://issues.apache.org/jira/browse/IGNITE-24945
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Exception:
{code:java}
2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.nio.channels.CancelledKeyException]]
java.nio.channels.CancelledKeyException: null
at
java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
~[?:?]
at
java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
~[?:?]
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
~[classes/:?]
at
org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
~[classes/:?]
at
org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
~[classes/:?]
at
org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
~[classes/:?]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
~[classes/:?]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
~[classes/:?]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
~[classes/:?]
{code}
Reason:
Multiple threads can access one SelectionKey. In this particular case it is -
tcp-comm-worker and grid-nio-worker.
1. tcp-comm-worker - checks that key is not closed by invoking
SelectionKey#isValid()
2. grid-nio-worker - closes the SelectionKey
3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24945) Node failure with java.nio.channels.CancelledKeyException on NIO SelectionKey closing.
[
https://issues.apache.org/jira/browse/IGNITE-24945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-24945:
Summary: Node failure with java.nio.channels.CancelledKeyException on NIO
SelectionKey closing. (was: Node failure in with
java.nio.channels.CancelledKeyException)
> Node failure with java.nio.channels.CancelledKeyException on NIO SelectionKey
> closing.
> --
>
> Key: IGNITE-24945
> URL: https://issues.apache.org/jira/browse/IGNITE-24945
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Critical
>
> Exception:
> {code:java}
> 2025-02-18 13:46:36.468 [ERROR][tcp-comm-worker-#1-#138][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.nio.channels.CancelledKeyException]]
> java.nio.channels.CancelledKeyException: null
> at
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:71)
> ~[?:?]
> at
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:90)
> ~[?:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.registerWrite(GridNioServer.java:2352)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionWrite(GridNioServer.java:3738)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslHandler.writeNetBuffer(GridNioSslHandler.java:502)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.shutdownSession(GridNioSslFilter.java:454)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onSessionClose(GridNioSslFilter.java:434)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionClose(GridConnectionBytesVerifyFilter.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionClose(GridNioCodecFilter.java:137)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionClose(GridNioFilterAdapter.java:128)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionClose(GridNioFilterChain.java:274)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionClose(GridNioFilterChain.java:203)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.close(GridNioSessionImpl.java:169)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl.close(GridSelectorNioSessionImpl.java:498)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.nio.GridTcpNioCommunicationClient.close(GridTcpNioCommunicationClient.java:81)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.processIdle(CommunicationWorker.java:278)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationWorker.body(CommunicationWorker.java:176)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3.body(TcpCommunicationSpi.java:848)
> ~[classes/:?]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[classes/:?]
> {code}
> Reason:
> Multiple threads can access one SelectionKey. In this particular case it is -
> tcp-comm-worker and grid-nio-worker.
> 1. tcp-comm-worker - checks that key is not closed by invoking
> SelectionKey#isValid()
> 2. grid-nio-worker - closes the SelectionKey
> 3. tcp-comm-worker - invokes SelectionKey#interestOps which raises
> CancelledKeyException, which in its turn leads to the node failure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24943) Storage already closed when handling safe time sync command
Roman Puchkovskiy created IGNITE-24943: -- Summary: Storage already closed when handling safe time sync command Key: IGNITE-24943 URL: https://issues.apache.org/jira/browse/IGNITE-24943 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy [2025-03-27T14:39:57,595][ERROR][%iirarct_irarc_3345%JRaft-FSMCaller-Disruptor_stripe_12-0][ZonePartitionRaftListener] Unknown error while processing command [commandIndex=358, commandTerm=358, command=SafeTimeSyncCommandImpl [initiatorTime=HybridTimestamp [physical=2025-03-27 10:39:57:583 +, logical=6, composite=114233966433599494], safeTime=null]] org.apache.ignite.internal.storage.StorageClosedException: Storage is already closed: [tableId=19, partitionId=15] at org.apache.ignite.internal.storage.util.StorageUtils.throwExceptionDependingOnStorageState(StorageUtils.java:140) ~[main/:?] at org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:647) ~[main/:?] at org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lastAppliedIndex(PersistentPageMemoryMvPartitionStorage.java:222) ~[main/:?] at org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.lastAppliedIndex(ThreadAssertingMvPartitionStorage.java:62) ~[main/:?] at org.apache.ignite.internal.table.distributed.raft.snapshot.SnapshotAwarePartitionDataStorage.lastAppliedIndex(SnapshotAwarePartitionDataStorage.java:112) ~[main/:?] at org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleSafeTimeSyncCommand(PartitionListener.java:514) ~[main/:?] at org.apache.ignite.internal.table.distributed.raft.PartitionListener.processCommand(PartitionListener.java:280) ~[main/:?] at org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.processCrossTableProcessorsCommand(ZonePartitionRaftListener.java:274) ~[main/:?] at org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.processWriteCommand(ZonePartitionRaftListener.java:210) ~[main/:?] at org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.lambda$onWrite$1(ZonePartitionRaftListener.java:161) ~[main/:?] at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) [?:?] at org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.onWrite(ZonePartitionRaftListener.java:159) [main/:?] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24828) Change behavior of ALTER ZONE with restriction on volatile to persistent storage profiles alteration
[ https://issues.apache.org/jira/browse/IGNITE-24828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-24828: Assignee: Mikhail Efremov > Change behavior of ALTER ZONE with restriction on volatile to persistent > storage profiles alteration > > > Key: IGNITE-24828 > URL: https://issues.apache.org/jira/browse/IGNITE-24828 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Efremov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24829) Update documentation on changed behavior of ALTER ZONE
[ https://issues.apache.org/jira/browse/IGNITE-24829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-24829: Assignee: Mikhail Efremov > Update documentation on changed behavior of ALTER ZONE > -- > > Key: IGNITE-24829 > URL: https://issues.apache.org/jira/browse/IGNITE-24829 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Efremov >Assignee: Mikhail Efremov >Priority: Major > Labels: docs, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24802) Investigate test "enter a node with an index greater than the current majority"
[ https://issues.apache.org/jira/browse/IGNITE-24802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-24802: - Description: Test from IGNITE-24785 fails because the node (with a raft log index greater than the current majority) is added to the raft table group without errors, which is incorrect, we need to figure out why this is happening and fix it. (was: Test from GNITE-24785 fails because the node (with a raft log index greater than the current majority) is added to the raft table group without errors, which is incorrect, we need to figure out why this is happening and fix it.) > Investigate test "enter a node with an index greater than the current > majority" > --- > > Key: IGNITE-24802 > URL: https://issues.apache.org/jira/browse/IGNITE-24802 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Test from IGNITE-24785 fails because the node (with a raft log index greater > than the current majority) is added to the raft table group without errors, > which is incorrect, we need to figure out why this is happening and fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Description:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM, and pattern
mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}} doesn't fail currently)
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
was:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM, and pattern
> mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
> 'DD-MM-YY')}} doesn't fail currently)
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Description:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE FORMAT
'-MM-DD')}}).
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
was:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-02' AS DATE FORMAT
'DD-MM-YY')}}).
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24941) IgniteUtils initial cleanup
[ https://issues.apache.org/jira/browse/IGNITE-24941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reassigned IGNITE-24941: -- Assignee: Ilya Shishkov > IgniteUtils initial cleanup > --- > > Key: IGNITE-24941 > URL: https://issues.apache.org/jira/browse/IGNITE-24941 > Project: Ignite > Issue Type: Sub-task >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Major > Labels: IEP-119, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24928) Improve node finder configuration
[ https://issues.apache.org/jira/browse/IGNITE-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-24928: --- Summary: Improve node finder configuration (was: Validate that node finder type is correct) > Improve node finder configuration > - > > Key: IGNITE-24928 > URL: https://issues.apache.org/jira/browse/IGNITE-24928 > Project: Ignite > Issue Type: Improvement >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > OneOf validation should be added for nodeFinder.type -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24942) StackOverflowError in PartitionMover
[ https://issues.apache.org/jira/browse/IGNITE-24942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24942: --- Description: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception as a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) was: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception is a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) > StackOverflowError in PartitionMover > > > Key: IGNITE-24942 > URL: https://issues.apache.org/jira/browse/IGNITE-24942 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > PartitionMover makes a retry on an exception. Retries are made on each > exception (including those that are not retriable), there is no retry limit > and the retries might happen in the same thread, which sometimes leads to an > infinite loop (resulting in StackOverflowException) is something is broken. > # We need to differentiate which exceptions are retryable and which are not > # For non-retryable ones, we should call FailureManager right away and stop > retrying > # For retryable ones, we should add a retry counter and stop handling an > exception as a retryable when the counter reaches some limit (that is, stop > retrying and notify FailureManager) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24938) Ignore attempts to create index storage in destroyed table storage
[ https://issues.apache.org/jira/browse/IGNITE-24938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24938: --- Description: IGNITE-24926 requires a lot of time to fix. This one is a fast and dirty workaround for it. The only problem that the race described in IGNITE-24926 causes is that, when creating an index storage (on index registration), we might get into a situation when the partition storage is already destroyed due to partition eviction initiated AFTER the index registration. The workaround is to quietly ignore such attempts. > Ignore attempts to create index storage in destroyed table storage > -- > > Key: IGNITE-24938 > URL: https://issues.apache.org/jira/browse/IGNITE-24938 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > IGNITE-24926 requires a lot of time to fix. This one is a fast and dirty > workaround for it. > The only problem that the race described in IGNITE-24926 causes is that, when > creating an index storage (on index registration), we might get into a > situation when the partition storage is already destroyed due to partition > eviction initiated AFTER the index registration. The workaround is to quietly > ignore such attempts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24943) Storage already closed when handling safe time sync command
[ https://issues.apache.org/jira/browse/IGNITE-24943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24943: --- Epic Link: IGNITE-22115 > Storage already closed when handling safe time sync command > --- > > Key: IGNITE-24943 > URL: https://issues.apache.org/jira/browse/IGNITE-24943 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > [2025-03-27T14:39:57,595][ERROR][%iirarct_irarc_3345%JRaft-FSMCaller-Disruptor_stripe_12-0][ZonePartitionRaftListener] > Unknown error while processing command [commandIndex=358, commandTerm=358, > command=SafeTimeSyncCommandImpl [initiatorTime=HybridTimestamp > [physical=2025-03-27 10:39:57:583 +, logical=6, > composite=114233966433599494], safeTime=null]] > org.apache.ignite.internal.storage.StorageClosedException: Storage is already > closed: [tableId=19, partitionId=15] > at > org.apache.ignite.internal.storage.util.StorageUtils.throwExceptionDependingOnStorageState(StorageUtils.java:140) > ~[main/:?] > at > org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:647) > ~[main/:?] > at > org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lastAppliedIndex(PersistentPageMemoryMvPartitionStorage.java:222) > ~[main/:?] > at > org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.lastAppliedIndex(ThreadAssertingMvPartitionStorage.java:62) > ~[main/:?] > at > org.apache.ignite.internal.table.distributed.raft.snapshot.SnapshotAwarePartitionDataStorage.lastAppliedIndex(SnapshotAwarePartitionDataStorage.java:112) > ~[main/:?] > at > org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleSafeTimeSyncCommand(PartitionListener.java:514) > ~[main/:?] > at > org.apache.ignite.internal.table.distributed.raft.PartitionListener.processCommand(PartitionListener.java:280) > ~[main/:?] > at > org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.processCrossTableProcessorsCommand(ZonePartitionRaftListener.java:274) > ~[main/:?] > at > org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.processWriteCommand(ZonePartitionRaftListener.java:210) > ~[main/:?] > at > org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.lambda$onWrite$1(ZonePartitionRaftListener.java:161) > ~[main/:?] > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) [?:?] > at > org.apache.ignite.internal.partition.replicator.raft.ZonePartitionRaftListener.onWrite(ZonePartitionRaftListener.java:159) > [main/:?] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24928) Improve node finder configuration
[ https://issues.apache.org/jira/browse/IGNITE-24928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-24928: - Fix Version/s: 3.1 > Improve node finder configuration > - > > Key: IGNITE-24928 > URL: https://issues.apache.org/jira/browse/IGNITE-24928 > Project: Ignite > Issue Type: Improvement >Reporter: Philipp Shergalis >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Polymorphic configuration should be used for static / multicast config > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24841) Optimize HybridTimestamp#toString
Kirill Tkalenko created IGNITE-24841: Summary: Optimize HybridTimestamp#toString Key: IGNITE-24841 URL: https://issues.apache.org/jira/browse/IGNITE-24841 Project: Ignite Issue Type: Improvement Environment: *org.apache.ignite.internal.hlc.HybridTimestamp* is used frequently in the project, including in logging, and it was found that *HybridTimestamp#toString* is slightly suboptimal and would be better refactored to regular concatenation. Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24946) Replace F.eq with the Objects.equals
Nikolay Izhikov created IGNITE-24946: Summary: Replace F.eq with the Objects.equals Key: IGNITE-24946 URL: https://issues.apache.org/jira/browse/IGNITE-24946 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Replace F.eq with the Objects.equals -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24946) Replace F.eq with the Objects.equals
[ https://issues.apache.org/jira/browse/IGNITE-24946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Davydov reassigned IGNITE-24946: --- Assignee: Maksim Davydov > Replace F.eq with the Objects.equals > > > Key: IGNITE-24946 > URL: https://issues.apache.org/jira/browse/IGNITE-24946 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Maksim Davydov >Priority: Major > > Replace F.eq with the Objects.equals -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24926) Race between index registration and replica destruction
[ https://issues.apache.org/jira/browse/IGNITE-24926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24926: --- Description: We initiate index registration in Metastore notification chain; this triggers index storages creation (asynchronously). Also, when a partition is evicted from a node (also triggered by an event coming from Metastore notification chain), this triggers table partition storage destruction; this also happens asynchronously as it requires I/O. These 2 kinds of activities must be linearized, and the order must be defined by the order of the triggering Metastore events. The problem is that this linearization is not guaranteed. The following might happen: # Index A is created and registered, its storages start to be created for every partition current node hosts (of the corresponding table) # Partition P of the corresponding table is evicted, its storage is destroyed # Only now index storage creation for partition P is executed, but the partition storage is already destroyed We need to introduce a linearization here, keeping in mind that the following must still be maintained: # Creation of table storage of partition P must precede its destruction (currently maintained) # Creation of index storage of partition P must precede its destruction (currently seems to be maintained) # Creation of index storage (and its registration in internal data structures) must precede writes to the index storage (currently seems to be maintained) Also, the following aspects affect performance and liveness: # Partition replica lifecycle management should not block Metastore notification chain (that is, async processes caused by partition replica lifecycle events should not hold Metastore revision completion; they need to be asynchronous wrt Metastore), otherwise deadlocks will occur (this is currently maintained) # Index storage registration should not hold Metastore revision completion (this is currently NOT maintained; this negatively affects Metastore performance, including Metastore SafeTime propagation, which might affect transaction processing) # Index storages should be > Race between index registration and replica destruction > --- > > Key: IGNITE-24926 > URL: https://issues.apache.org/jira/browse/IGNITE-24926 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > We initiate index registration in Metastore notification chain; this triggers > index storages creation (asynchronously). Also, when a partition is evicted > from a node (also triggered by an event coming from Metastore notification > chain), this triggers table partition storage destruction; this also happens > asynchronously as it requires I/O. These 2 kinds of activities must be > linearized, and the order must be defined by the order of the triggering > Metastore events. > The problem is that this linearization is not guaranteed. The following might > happen: > # Index A is created and registered, its storages start to be created for > every partition current node hosts (of the corresponding table) > # Partition P of the corresponding table is evicted, its storage is destroyed > # Only now index storage creation for partition P is executed, but the > partition storage is already destroyed > We need to introduce a linearization here, keeping in mind that the following > must still be maintained: > # Creation of table storage of partition P must precede its destruction > (currently maintained) > # Creation of index storage of partition P must precede its destruction > (currently seems to be maintained) > # Creation of index storage (and its registration in internal data > structures) must precede writes to the index storage (currently seems to be > maintained) > Also, the following aspects affect performance and liveness: > # Partition replica lifecycle management should not block Metastore > notification chain (that is, async processes caused by partition replica > lifecycle events should not hold Metastore revision completion; they need to > be asynchronous wrt Metastore), otherwise deadlocks will occur (this is > currently maintained) > # Index storage registration should not hold Metastore revision completion > (this is currently NOT maintained; this negatively affects Metastore > performance, including Metastore SafeTime propagation, which might affect > transaction processing) > # Index storages should be -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-24909:
--
Description:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE FORMAT
'-MM-DD')}}).
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
was:
Date/time formatting tests currently located in {{test_cast_format.test}}, but
the tests look incomplete.
Need to improve checks for boundary values and templates (see 9.44 Datetime
templates):
* Incorrect templates, for example Y, FF0, FF10, MMM,
* Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE FORMAT
'-MM-DD')}}).
* Cast values with overflow, for example cast('-00-00' as date format
'-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
strange results
* Add test for cast with precision greater than zero (for example SELECT
cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
* Add tests that uses dynamic parameters
* Add tests that uses table columns
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24942) StackOverflowError in PartitionMover
[ https://issues.apache.org/jira/browse/IGNITE-24942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24942: --- Description: PartitionMover makes a retry on an exception. Retries are made on each exception (including those that are not retriable), there is no retry limit and the retries might happen in the same thread, which sometimes leads to an infinite loop (resulting in StackOverflowException) is something is broken. # We need to differentiate which exceptions are retryable and which are not # For non-retryable ones, we should call FailureManager right away and stop retrying # For retryable ones, we should add a retry counter and stop handling an exception is a retryable when the counter reaches some limit (that is, stop retrying and notify FailureManager) > StackOverflowError in PartitionMover > > > Key: IGNITE-24942 > URL: https://issues.apache.org/jira/browse/IGNITE-24942 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > PartitionMover makes a retry on an exception. Retries are made on each > exception (including those that are not retriable), there is no retry limit > and the retries might happen in the same thread, which sometimes leads to an > infinite loop (resulting in StackOverflowException) is something is broken. > # We need to differentiate which exceptions are retryable and which are not > # For non-retryable ones, we should call FailureManager right away and stop > retrying > # For retryable ones, we should add a retry counter and stop handling an > exception is a retryable when the counter reaches some limit (that is, stop > retrying and notify FailureManager) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22724) (flaky) aimem: node doesn't recover after data clean and goes into state BROKEN
[
https://issues.apache.org/jira/browse/IGNITE-22724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Dmitrienko resolved IGNITE-22724.
--
Resolution: Cannot Reproduce
No longer reproducible.
> (flaky) aimem: node doesn't recover after data clean and goes into state
> BROKEN
> ---
>
> Key: IGNITE-22724
> URL: https://issues.apache.org/jira/browse/IGNITE-22724
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0
> Environment: 3 distributed nodes (with 1 CMG), storage AIMEM
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: servers_logs.zip
>
>
> *{color:#de350b}This issue sometimes is replaced by
> https://issues.apache.org/jira/browse/IGNITE-22725{color}*
>
> *Steps to reproduce:*
> # Create 3 nodes cluster with 1 CMG node (node_0 - CMG,node_1,node_2).
> # Create zone with replication equals to amount of nodes (3).
> # Create 10 tables inside the zone.
> # Insert 100 rows in every table.
> # Await all tables*partitions*nodes local state is "HEALTHY"
> # Await all tables*partitions*nodes global state is "AVAILABLE"
> # Kill non CMG node with kill -9. (kill node_1)
> # Clean data in work directory of killed node (node_1).
> # Start killed node.
> # Using REST API await *physical* topology has 3 alive nodes.
> # Using REST API await *logical* topology has 3 alive nodes.
> # Await all tables*partitions*nodes local state is "HEALTHY" (by connecting
> to REST of node_2).
> *Expected:*
> All partitions become "HEALTHY".
> *Actual:*
> Partitions in sates: "HEALTHY" and "BROKEN". [^servers_logs.zip]
> *Comments:*
> This test works fine with aipersist storage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24926) Race between index registration and replica destruction
[ https://issues.apache.org/jira/browse/IGNITE-24926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24926: --- Description: We initiate index registration in Metastore notification chain; this triggers index storages creation (asynchronously). Also, when a partition is evicted from a node (also triggered by an event coming from Metastore notification chain), this triggers table partition storage destruction; this also happens asynchronously as it requires I/O. These 2 kinds of activities must be linearized, and the order must be defined by the order of the triggering Metastore events. The problem is that this linearization is not guaranteed. The following might happen: # Index A is created and registered, its storages start to be created for every partition current node hosts (of the corresponding table) # Partition P of the corresponding table is evicted, its storage is destroyed # Only now index storage creation for partition P is executed, but the partition storage is already destroyed We need to introduce a linearization here, keeping in mind that the following must still be maintained: # Creation of table storage of partition P must precede its destruction (currently maintained) # Creation of index storage of partition P must precede its destruction (currently seems to be maintained) # Creation of index storage (and its registration in internal data structures) must precede writes to the index storage (currently seems to be maintained) Also, the following aspects affect performance and liveness: # Partition replica lifecycle management should not block Metastore notification chain (that is, async processes caused by partition replica lifecycle events should not hold Metastore revision completion; they need to be asynchronous wrt Metastore), otherwise deadlocks will occur (this is currently maintained) # Index storage registration should not hold Metastore revision completion (this is currently NOT maintained; this negatively affects Metastore performance, including Metastore SafeTime propagation, which might affect transaction processing) This seems to require a thorough design. was: We initiate index registration in Metastore notification chain; this triggers index storages creation (asynchronously). Also, when a partition is evicted from a node (also triggered by an event coming from Metastore notification chain), this triggers table partition storage destruction; this also happens asynchronously as it requires I/O. These 2 kinds of activities must be linearized, and the order must be defined by the order of the triggering Metastore events. The problem is that this linearization is not guaranteed. The following might happen: # Index A is created and registered, its storages start to be created for every partition current node hosts (of the corresponding table) # Partition P of the corresponding table is evicted, its storage is destroyed # Only now index storage creation for partition P is executed, but the partition storage is already destroyed We need to introduce a linearization here, keeping in mind that the following must still be maintained: # Creation of table storage of partition P must precede its destruction (currently maintained) # Creation of index storage of partition P must precede its destruction (currently seems to be maintained) # Creation of index storage (and its registration in internal data structures) must precede writes to the index storage (currently seems to be maintained) Also, the following aspects affect performance and liveness: # Partition replica lifecycle management should not block Metastore notification chain (that is, async processes caused by partition replica lifecycle events should not hold Metastore revision completion; they need to be asynchronous wrt Metastore), otherwise deadlocks will occur (this is currently maintained) # Index storage registration should not hold Metastore revision completion (this is currently NOT maintained; this negatively affects Metastore performance, including Metastore SafeTime propagation, which might affect transaction processing) # Index storages should be > Race between index registration and replica destruction > --- > > Key: IGNITE-24926 > URL: https://issues.apache.org/jira/browse/IGNITE-24926 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > We initiate index registration in Metastore notification chain; this triggers > index storages creation (asynchronously). Also, when a partition is evicted > from a node (also triggered by an event coming from Metastore notification > chain), this triggers table partition storage
[jira] [Resolved] (IGNITE-23817) Tables creation in 10 threads throws "Send with retry timed out"
[
https://issues.apache.org/jira/browse/IGNITE-23817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Dmitrienko resolved IGNITE-23817.
--
Resolution: Cannot Reproduce
No longer reproducible.
> Tables creation in 10 threads throws "Send with retry timed out"
>
>
> Key: IGNITE-23817
> URL: https://issues.apache.org/jira/browse/IGNITE-23817
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0, 3.0.0-beta1
> Environment: 3 nodes (each node is CMG, each node
> {color:#067d17}"-Xms4096m"{color}, {color:#067d17}"-Xmx4096m"{color}), each
> on separate host. Each host vCPU: 4, Memory: 32GB.
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments:
> 20241202_034128_45_TablesAmountCapacityMultiNodeTest_cluster.zip
>
>
> *Steps to reproduce:*
> # Start 3 nodes (each node is CMG, each node
> {color:#067d17}"-Xms4096m"{color}, {color:#067d17}"-Xmx4096m"{color}), each
> on separate host. Each host vCPU: 4, Memory: 32GB.
> # Create 50 tables with 5 columns in 10 threads.
> # Assert 50 tables are present in system view.
> # Insert 1 row into each.
> # Assert rows content is correct in 10 threads.
> # Repeat steps 2-5 while amount of tables is 1000.
> *Expected:*
> 1000 tables are created.
> *Actual:*
> Exception during 500-549 tables creation at step 4.
>
> {code:java}
> org.opentest4j.AssertionFailedError: org.opentest4j.AssertionFailedError:
> Execute: Insert row into tables 500 - 549 in 10 threads ==> Unexpected
> exception thrown: java.util.concurrent.ExecutionException:
> java.sql.SQLException: Send with retry timed out [retryCount = 2, groupId =
> 1023_part_11, traceId = 2b26c51f-5d03-4ac5-ba12-144cdc1b9e22, request =
> org.apache.ignite.raft.jraft.rpc.WriteActionRequestImpl(org.apache.ignite.internal.partition.replicator.network.command.UpdateCommandImpl),
> originCommand = null].
> org.opentest4j.AssertionFailedError: Execute: Insert row into tables 500 -
> 549 in 10 threads ==> Unexpected exception thrown:
> java.util.concurrent.ExecutionException: java.sql.SQLException: Send with
> retry timed out [retryCount = 2, groupId = 1023_part_11, traceId =
> 2b26c51f-5d03-4ac5-ba12-144cdc1b9e22, request =
> org.apache.ignite.raft.jraft.rpc.WriteActionRequestImpl(org.apache.ignite.internal.partition.replicator.network.command.UpdateCommandImpl),
> originCommand = null].
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.createAssertionFailedError(AssertDoesNotThrow.java:84)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:53)
> at
> app//org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:40)
> at
> app//org.junit.jupiter.api.Assertions.assertDoesNotThrow(Assertions.java:3183)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityBaseTest.lambda$invokeTasks$14(TablesAmountCapacityBaseTest.java:381)
> at app//io.qameta.allure.Allure.lambda$step$0(Allure.java:113)
> at app//io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at app//io.qameta.allure.Allure.step(Allure.java:181)
> at app//io.qameta.allure.Allure.step(Allure.java:125)
> at app//io.qameta.allure.Allure.step(Allure.java:112)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityBaseTest.step(TablesAmountCapacityBaseTest.java:271)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityBaseTest.invokeTasks(TablesAmountCapacityBaseTest.java:376)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityBaseTest.insertRowInTablesParallel(TablesAmountCapacityBaseTest.java:183)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityBaseTest.testTablesAmount(TablesAmountCapacityBaseTest.java:92)
> at
> app//org.gridgain.ai3tests.tests.amountcapacity.TablesAmountCapacityMultiNodeTest.create1000EmptyTablesAmountOfColumnsEachAndMakeSimpleQueries(TablesAmountCapacityMultiNodeTest.java:97)
> at java.base@21.0.2/java.lang.reflect.Method.invoke(Method.java:580)
> at
> app//io.qameta.allure.junit5.AllureJunit5.interceptTestTemplateMethod(AllureJunit5.java:59)
> at java.base@21.0.2/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base@21.0.2/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base@21.0.2/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base@21.0.2/java.lang.Thread.run(Thread.java:1583)
> Caused by: java.util.concurrent.ExecutionException: java.sql.SQLException:
> Send with retry timed out [ret
[jira] [Resolved] (IGNITE-24136) [FLAKY] BROKEN state after node restart in cluster of 2 nodes
[
https://issues.apache.org/jira/browse/IGNITE-24136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Dmitrienko resolved IGNITE-24136.
--
Resolution: Cannot Reproduce
No longer reproducible.
> [FLAKY] BROKEN state after node restart in cluster of 2 nodes
> -
>
> Key: IGNITE-24136
> URL: https://issues.apache.org/jira/browse/IGNITE-24136
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta1
> Environment: 2 nodes (1 node is CMG, each node
> {color:#067d17}"{color}{color:#067d17}-Xms512m"{color},
> {color:#067d17}"-Xmx1536m{color}{color:#067d17}"{color}), each on separate
> host. Each host vCPU: 4, Memory: 32GB.
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: server_logs.zip
>
>
> # Start 2 nodes (1 node is CMG, each node {color:#067d17}"-Xms512m"{color},
> {color:#067d17}"-Xmx1536m"{color}), each on separate host. Each host vCPU: 4,
> Memory: 32GB.
> # Create 10 tables
> ## Execute query: create zone if not exists "cluster_failover_2" with
> replicas=2, data_nodes_auto_adjust_scale_up=10,
> data_nodes_auto_adjust_scale_down=10, storage_profiles='default_aipersist'
> ## Execute query: create TABLE failoverTest00(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest01(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest02(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest03(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest04(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest05(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest06(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest07(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest08(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> ## Execute query: create TABLE failoverTest09(k1 INTEGER not null, k2
> INTEGER not null, v1 VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null,
> primary key (k1, k2)) ZONE "cluster_failover_2"
> # Fill tables with 1000 rows each
> # Await all partitions of all tables local state is "HEALTHY"
> # Await all partitions of all tables global state is "AVAILABLE"
> # Assert the tables has been filled, with expected row count of '1000' and
> no errors in logs
> ## Assert that ignite log contains no errors or exceptions
> # Kill node (not CMG) and start it again
> # Assert physical and logical topologies are correct
> # Await all partitions of all tables local state is "HEALTHY"
> *Expected:*
> Steps are executed successfully.
> *Actual:*
> Actual states: HEALTHY, BROKEN
> [^server_logs.zip]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938956#comment-17938956
]
Pavel Pereslegin commented on IGNITE-24909:
---
Calcite uses SimpleDateFormat to parse dates internally, so issues with
possible invalid/wrong patterns and overflows are related to Java's
SimpleDateFormat.
For example the following is acceptable for SimpleDateFormat:
{code:java}
DateFormat df = new SimpleDateFormat("yy-MM-dd", Locale.ENGLISH);
System.out.println(df.parse("999-999-999")); // Sun Dec 27
00:00:00 MSK 998
{code}
And the same is acceptable by Calcite
{code:java}
sql("SELECT CAST('999-999-999' AS DATE FORMAT 'yy-MM-dd')"); //
[[-898510-03-05]]
{code}
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-24540) Creating 1000 tables with 200 columns throws "The primary replica has changed"
[
https://issues.apache.org/jira/browse/IGNITE-24540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Dmitrienko resolved IGNITE-24540.
--
Resolution: Cannot Reproduce
No longer reproducible.
> Creating 1000 tables with 200 columns throws "The primary replica has changed"
> --
>
> Key: IGNITE-24540
> URL: https://issues.apache.org/jira/browse/IGNITE-24540
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0, 3.0.0-beta1
> Environment: 3 nodes (each node is CMG, each node
> {color:#067d17}"-Xms4096m"{color}, {color:#067d17}"-Xmx4096m"{color}), each
> on separate host. Each host vCPU: 4, Memory: 32GB.
>Reporter: Vladimir Dmitrienko
>Priority: Major
> Labels: ignite-3
> Attachments: node_1_logs.zip, node_2_logs.zip, node_3_logs.zip,
> test.log
>
>
> *Steps to reproduce:*
> # Start 3 nodes (each node is CMG, each node
> {color:#067d17}"-Xms4096m"{color}, {color:#067d17}"-Xmx4096m"{color}), each
> on separate host. Each host vCPU: 4, Memory: 32GB.
> # Create 50 tables with 200 columns in 1 thread.
> # Assert 50 tables are present in system view.
> # Insert 1 row into each.
> # Assert rows content is correct.
> # Repeat steps 2-5 while amount of tables is 1000.
> *Expected:*
> 1000 tables are created.
> *Actual:*
> Exception during 400 - 449 tables creation at step 5.
> {code:java}
> java.sql.SQLException:
> The primary replica has changed [
> expectedLeaseholderName=TablesAmountCapacityMultiNodeTest_cluster_2,
> currentLeaseholderName=null,
> expectedLeaseholderId=1522cfcd-0400-4d23-9015-31dfbad90780,
> currentLeaseholderId=null,
> expectedEnlistmentConsistencyToken=114017056457556334,
> currentEnlistmentConsistencyToken=null
> ]{code}
> Based on the information in the exception, it appears to have been thrown
> from the {{PartitionReplicaListener#ensureReplicaIsPrimary}} method.
> *Notes:*
> The issue might be related to:
> https://issues.apache.org/jira/browse/IGNITE-20911
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-24909) Sql. Improve test coverage for date/time templates support
[
https://issues.apache.org/jira/browse/IGNITE-24909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938956#comment-17938956
]
Pavel Pereslegin edited comment on IGNITE-24909 at 3/27/25 2:21 PM:
Calcite uses SimpleDateFormat to parse dates internally, so issues with
possible invalid/wrong patterns and overflows are caused by Java's
SimpleDateFormat usage without additional validations.
For example the following is acceptable for SimpleDateFormat:
{code:java}
DateFormat df = new SimpleDateFormat("yy-MM-dd", Locale.ENGLISH);
System.out.println(df.parse("999-999-999")); // Sun Dec 27
00:00:00 MSK 998
{code}
And the same is acceptable by Calcite
{code:java}
sql("SELECT CAST('999-999-999' AS DATE FORMAT 'yy-MM-dd')"); //
[[-898510-03-05]]
{code}
was (Author: xtern):
Calcite uses SimpleDateFormat to parse dates internally, so issues with
possible invalid/wrong patterns and overflows are related to Java's
SimpleDateFormat.
For example the following is acceptable for SimpleDateFormat:
{code:java}
DateFormat df = new SimpleDateFormat("yy-MM-dd", Locale.ENGLISH);
System.out.println(df.parse("999-999-999")); // Sun Dec 27
00:00:00 MSK 998
{code}
And the same is acceptable by Calcite
{code:java}
sql("SELECT CAST('999-999-999' AS DATE FORMAT 'yy-MM-dd')"); //
[[-898510-03-05]]
{code}
> Sql. Improve test coverage for date/time templates support
> --
>
> Key: IGNITE-24909
> URL: https://issues.apache.org/jira/browse/IGNITE-24909
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Date/time formatting tests currently located in {{test_cast_format.test}},
> but the tests look incomplete.
> Need to improve checks for boundary values and templates (see 9.44 Datetime
> templates):
> * Incorrect templates, for example Y, FF0, FF10, MMM,
> * Pattern mismatching (for example {{SELECT CAST('2021-01-' AS DATE
> FORMAT '-MM-DD')}}).
> * Cast values with overflow, for example cast('-00-00' as date format
> '-MM-DD') or cast('-99-99' as date format '-MM-DD') produces
> strange results
> * Add test for cast with precision greater than zero (for example SELECT
> cast('01:05:07.161' as time(*2*) format 'HH24:MI:SS.FF1'))
> * Add tests that uses dynamic parameters
> * Add tests that uses table columns
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
