[jira] [Assigned] (IGNITE-21984) Extend test coverage for SQL T621(Enhanced numeric functions)
[ https://issues.apache.org/jira/browse/IGNITE-21984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21984: --- Assignee: Evgeny Stanilovsky > Extend test coverage for SQL T621(Enhanced numeric functions) > - > > Key: IGNITE-21984 > URL: https://issues.apache.org/jira/browse/IGNITE-21984 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T621(Enhanced numeric functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21537) Connection refused exception contains 800 lines
[
https://issues.apache.org/jira/browse/IGNITE-21537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846735#comment-17846735
]
Alexander Belyak commented on IGNITE-21537:
---
Still getting 150+ lines like:
{noformat}
2024-05-15 17:44:22:401 +
[WARNING][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-AppendEntries-Processor-1][Replicator]
Fail to issue RPC to poc-tester-SERVER-172.24.1.2-id-0,
consecutiveErrorTimes=100, error=Status[EINTERNAL<1004>: Check
connection[poc-tester-SERVER-172.24.1.2-id-0] fail and try to create new one]
2024-05-15 17:44:22:513 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:523 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-3][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:635 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:644 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-6][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:757 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:767 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:878 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-0][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:22:900 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:000 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-4][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:021 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:022 +
[WARNING][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-AppendEntries-Processor-1][Replicator]
Fail to issue RPC to poc-tester-SERVER-172.24.1.2-id-0,
consecutiveErrorTimes=110, error=Status[EINTERNAL<1004>: Check
connection[poc-tester-SERVER-172.24.1.2-id-0] fail and try to create new one]
2024-05-15 17:44:23:122 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-1][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:144 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-3][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:244 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-2][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
2024-05-15 17:44:23:265 +
[ERROR][%poc-tester-SERVER-172.24.1.4-id-0%JRaft-Common-Executor-7][AbstractClientService]
Fail to connect poc-tester-SERVER-172.24.1.2-id-0, exception:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/172.24.1.2:3344.
{noformat}
It makes server logs difficult to read.
> Connection refused
[jira] [Updated] (IGNITE-22094) Add removeAll method to tx state storage
[ https://issues.apache.org/jira/browse/IGNITE-22094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-22094: -- Fix Version/s: 3.0.0-beta2 > Add removeAll method to tx state storage > > > Key: IGNITE-22094 > URL: https://issues.apache.org/jira/browse/IGNITE-22094 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *Motivation* > Tx state vacuum should be able to remove multiple tx states at once - all of > them that meet requirements for removal. > *Definition of done* > TxStateStorage#removeAll is added, along with corresponding tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22183) Adding events recording for Index Queries
[ https://issues.apache.org/jira/browse/IGNITE-22183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22183: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Adding events recording for Index Queries > - > > Key: IGNITE-22183 > URL: https://issues.apache.org/jira/browse/IGNITE-22183 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Recording of Cache Query Read Object events and Cache Query Execution events > need to be added for Index Queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22183) Adding events recording for Index Queries
[ https://issues.apache.org/jira/browse/IGNITE-22183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22183: Fix Version/s: 2.17 > Adding events recording for Index Queries > - > > Key: IGNITE-22183 > URL: https://issues.apache.org/jira/browse/IGNITE-22183 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Recording of Cache Query Read Object events and Cache Query Execution events > need to be added for Index Queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21809) Sql. Improve intra-query parallelism
[ https://issues.apache.org/jira/browse/IGNITE-21809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-21809: - Assignee: Konstantin Orlov > Sql. Improve intra-query parallelism > > > Key: IGNITE-21809 > URL: https://issues.apache.org/jira/browse/IGNITE-21809 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > At the moment, intra-query parallelism is achieved by splitting the query on > several fragments in the place where distribution conversion is required, but > the fragment itself is tied up to a single thread. Such a parallelization > results in a low resource utilization by a single query, especially in case > of huge fragments like the ones containing aggregation or colocated joins. > Let's investigate possible solutions and make a POC -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20450) Failure handler configuration
[ https://issues.apache.org/jira/browse/IGNITE-20450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20450: Assignee: Vyacheslav Koptilin > Failure handler configuration > - > > Key: IGNITE-20450 > URL: https://issues.apache.org/jira/browse/IGNITE-20450 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > *Motivation:* > The user should be able to configure the following properties related to > failure handling: > - first of all, the user should be able to choose a concrete strategy of > failure handling from the provided out-of-the-box: _StopNodeFailureHandler_, > _StopNodeOrHaltFailureHandler_. The default value is _StopNodeFailureHandler_. > - Enabling thread dump on failure. The default value is _true_. > - Timeout for throttling of thread dumps generation. The default value is > 10sec. > - System worker blocked timeout. The default value is 10sec. > - Size of buffer that is used to handle OOM. The default value is 64Kb. > - Perhaps, it can be useful to configure a list of ignored failure types. > The default value is: _SYSTEM_WORKER_BLOCKED_, > _SYSTEM_CRITICAL_OPERATION_TIMEOUT_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22250) Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22250:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky
>
>
> Key: IGNITE-22250
> URL: https://issues.apache.org/jira/browse/IGNITE-22250
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: <1.71580418E12> but was:
> <1.71580405E12>
> at
> app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:866)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22250) Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22250:
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: <1.71580418E12> but was:
<1.71580405E12>
at
app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:866)
{code}
> Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky
>
>
> Key: IGNITE-22250
> URL: https://issues.apache.org/jira/browse/IGNITE-22250
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: <1.71580418E12> but was:
> <1.71580405E12>
> at
> app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:866)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22250) Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky
Pavel Tupitsyn created IGNITE-22250: --- Summary: Java thin: ItSqlClientSynchronousApiTest.testTimeZoneId is flaky Key: IGNITE-22250 URL: https://issues.apache.org/jira/browse/IGNITE-22250 Project: Ignite Issue Type: Bug Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22249) Add more GC metrics
[ https://issues.apache.org/jira/browse/IGNITE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22249: --- Description: Currently, we have only one GC metric: jvm.gc.CollectionTime. It's a sume across all collectors. More details can be exported about GC as metrics. The difficulty here is that a JVM might have more than one GCs (for example, Java 11 has G1 Young Gen and G1 Old Gen collectors by default). We need to invent a way to present this information as metrics for all collectors. A few approaches are possible (maybe there are more): # Ignite 2 has just one metric for a sum of CollectionTime # We might classify collectors as major/minor and output their metrics separately. This is something like [DataLog|https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/] does. # [OpenTelemetry|https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/] annotates each datapoint with collectorName. Our metrics system does not have annotations though. # Just use dynamic metrics where metric key would contain a (possibly transformed) collector name, like jvm.gc..CollectionTime. > Add more GC metrics > --- > > Key: IGNITE-22249 > URL: https://issues.apache.org/jira/browse/IGNITE-22249 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > Currently, we have only one GC metric: jvm.gc.CollectionTime. It's a sume > across all collectors. > More details can be exported about GC as metrics. The difficulty here is that > a JVM might have more than one GCs (for example, Java 11 has G1 Young Gen and > G1 Old Gen collectors by default). We need to invent a way to present this > information as metrics for all collectors. > A few approaches are possible (maybe there are more): > # Ignite 2 has just one metric for a sum of CollectionTime > # We might classify collectors as major/minor and output their metrics > separately. This is something like > [DataLog|https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/] > does. > # > [OpenTelemetry|https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/] > annotates each datapoint with collectorName. Our metrics system does not > have annotations though. > # Just use dynamic metrics where metric key would contain a (possibly > transformed) collector name, like jvm.gc..CollectionTime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22249) Add more GC metrics
Roman Puchkovskiy created IGNITE-22249: -- Summary: Add more GC metrics Key: IGNITE-22249 URL: https://issues.apache.org/jira/browse/IGNITE-22249 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22135) Sql. Investigate get ride support of CHAR datatype.
[ https://issues.apache.org/jira/browse/IGNITE-22135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-22135: -- Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > Sql. Investigate get ride support of CHAR datatype. > --- > > Key: IGNITE-22135 > URL: https://issues.apache.org/jira/browse/IGNITE-22135 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > CHAR type is not widely used by users, however, the type has specific need to > be supported and requires significant time to do it right. > Let's consider the ability to get rid of the type. > List possibility solutions ordered by priority: > 1. Make CHAR type an alias for VARCHAR, but take into account that in the > future we can start supporting the type in the right way and need to be sure > we can support smooth migration from the version that does not support CHAR > to the new one with such support ( as example - metadata for such type should > reflect real type VARCHAR) > 2. Forbid CHAR type at all. No alias even. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22135) Sql. Investigate get ride support of CHAR datatype.
[ https://issues.apache.org/jira/browse/IGNITE-22135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-22135: -- Fix Version/s: 3.0.0-beta2 > Sql. Investigate get ride support of CHAR datatype. > --- > > Key: IGNITE-22135 > URL: https://issues.apache.org/jira/browse/IGNITE-22135 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > CHAR type is not widely used by users, however, the type has specific need to > be supported and requires significant time to do it right. > Let's consider the ability to get rid of the type. > List possibility solutions ordered by priority: > 1. Make CHAR type an alias for VARCHAR, but take into account that in the > future we can start supporting the type in the right way and need to be sure > we can support smooth migration from the version that does not support CHAR > to the new one with such support ( as example - metadata for such type should > reflect real type VARCHAR) > 2. Forbid CHAR type at all. No alias even. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22208) Deduplicate DEFAULT_SCHEMA_NAME
[
https://issues.apache.org/jira/browse/IGNITE-22208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846616#comment-17846616
]
Pavel Tupitsyn commented on IGNITE-22208:
-
Merged to main:
[bd4574da15154fb17c258c42f479b7ec1bc154a6|https://github.com/apache/ignite-3/commit/bd4574da15154fb17c258c42f479b7ec1bc154a6]
> Deduplicate DEFAULT_SCHEMA_NAME
> ---
>
> Key: IGNITE-22208
> URL: https://issues.apache.org/jira/browse/IGNITE-22208
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following constant is duplicated 6 times currently:
> {code:java}
> DEFAULT_SCHEMA_NAME = "PUBLIC"
> {code}
> * Let's put it somewhere in the core module and reuse.
> * It should *not* be a part of the public API. For internal use only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21830) Add logging of connection check for each address
[
https://issues.apache.org/jira/browse/IGNITE-21830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846586#comment-17846586
]
Ignite TC Bot commented on IGNITE-21830:
{panel:title=Branch: [pull/11327/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11327/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI (Discovery){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7868001]]
* {color:#013220}IgniteSpiDiscoverySelfTestSuite:
TcpDiscoveryNetworkIssuesTest.testBackwardConnectionCheckFailedLogMessage -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7868020buildTypeId=IgniteTests24Java8_RunAll]
> Add logging of connection check for each address
>
>
> Key: IGNITE-21830
> URL: https://issues.apache.org/jira/browse/IGNITE-21830
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 13h
> Remaining Estimate: 0h
>
> Currently, exception thrown during checking of address is ignored [1]. It
> would be useful to print message with connection check summary including each
> address checking state and error message (if any).
> #
> https://github.com/apache/ignite/blob/7cd0c7a7d1150bbf6be6aae5efe80627a73757c0/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L7293
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22247) Handle 'partition cannot be started at Ignite node startup' situation
[ https://issues.apache.org/jira/browse/IGNITE-22247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22247: --- Description: Sometimes, a partition cannot be started during node startup (due to a bug). In tests, it makes sense to fail node start to make the problem visible. But in production it probably makes sense to start whatever partititions we can and let the user know that some partitions are in a 'broken' state. Currently, we just ignore such errors. The proposal is to make this 'brokenness' information available via partition state API and partition state metrics. In tests, we can query the API/metrics and fail the node if some partition is broken. > Handle 'partition cannot be started at Ignite node startup' situation > - > > Key: IGNITE-22247 > URL: https://issues.apache.org/jira/browse/IGNITE-22247 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > Sometimes, a partition cannot be started during node startup (due to a bug). > In tests, it makes sense to fail node start to make the problem visible. But > in production it probably makes sense to start whatever partititions we can > and let the user know that some partitions are in a 'broken' state. > Currently, we just ignore such errors. > The proposal is to make this 'brokenness' information available via partition > state API and partition state metrics. In tests, we can query the API/metrics > and fail the node if some partition is broken. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22248) Creation of new tables in 1 node cluster stuck after 850+ tables
[
https://issues.apache.org/jira/browse/IGNITE-22248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-22248:
--
Description:
*Steps to reproduce:*
# Single node cluster with arguments "-Xms4096m", "-Xmx4096m"
# Create tables one by one up to 1000
*Expected:*
1000 tables are created.
*Actual:*
After 850+ tables the creation time is higher than 30 seconds.
!image-2024-05-15-13-22-40-059.png!
In the server logs continuous errors:
{code:java}
2024-05-15 04:11:58:116 +
[WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable
error during the request occurred (will be retried on the randomly selected
node) [request=WriteActionRequestImpl [command=[0, 9, 41, -126, -128, -36, -49,
-79, -50, -34, -57, 1], deserializedCommand=SafeTimeSyncCommandImpl
[safeTimeLong=112443150482997249], groupId=950_part_21], peer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0], newPeer=Peer
[consistentId=TablesAmountCapacityTest_cluster_0, idx=0]].
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:368)
at
java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:377)
at
java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1097)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
at
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2874)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.util.concurrent.TimeoutException
... 7 more {code}
was:
*Steps to reproduce:*
# Multinode cluster (3 nodes) with arguments
"-Xms4096m", "-Xmx4096m"
# Create tables one by one up to 1000
*Expected:*
1000 tables are created.
*Actual:*
After 150+ tables the creation time is higher than 30 seconds.
!image-2024-05-13-10-22-06-994.png!
> Creation of new tables in 1 node cluster stuck after 850+ tables
>
>
> Key: IGNITE-22248
> URL: https://issues.apache.org/jira/browse/IGNITE-22248
> Project: Ignite
> Issue Type: Bug
> Components: general, persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-05-15-13-22-40-059.png
>
>
> *Steps to reproduce:*
> # Single node cluster with arguments "-Xms4096m", "-Xmx4096m"
> # Create tables one by one up to 1000
> *Expected:*
> 1000 tables are created.
> *Actual:*
> After 850+ tables the creation time is higher than 30 seconds.
> !image-2024-05-15-13-22-40-059.png!
> In the server logs continuous errors:
> {code:java}
> 2024-05-15 04:11:58:116 +
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable
> error during the request occurred (will be retried on the randomly selected
> node) [request=WriteActionRequestImpl [command=[0, 9, 41, -126, -128, -36,
> -49, -79, -50, -34, -57, 1], deserializedCommand=SafeTimeSyncCommandImpl
> [safeTimeLong=112443150482997249], groupId=950_part_21], peer=Peer
> [consistentId=TablesAmountCapacityTest_cluster_0, idx=0], newPeer=Peer
> [consistentId=TablesAmountCapacityTest_cluster_0, idx=0]].
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:368)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:377)
> at
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1097)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
> at
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2874)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at
[jira] [Updated] (IGNITE-22248) Creation of new tables in 1 node cluster stuck after 850+ tables
[ https://issues.apache.org/jira/browse/IGNITE-22248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor updated IGNITE-22248: -- Attachment: image-2024-05-15-13-22-40-059.png > Creation of new tables in 1 node cluster stuck after 850+ tables > > > Key: IGNITE-22248 > URL: https://issues.apache.org/jira/browse/IGNITE-22248 > Project: Ignite > Issue Type: Bug > Components: general, persistence >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > Attachments: image-2024-05-15-13-22-40-059.png > > > *Steps to reproduce:* > # Multinode cluster (3 nodes) with arguments > "-Xms4096m", "-Xmx4096m" > # Create tables one by one up to 1000 > *Expected:* > 1000 tables are created. > *Actual:* > After 150+ tables the creation time is higher than 30 seconds. > !image-2024-05-13-10-22-06-994.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22248) Creation of new tables in 1 node cluster stuck after 850+ tables
Igor created IGNITE-22248: - Summary: Creation of new tables in 1 node cluster stuck after 850+ tables Key: IGNITE-22248 URL: https://issues.apache.org/jira/browse/IGNITE-22248 Project: Ignite Issue Type: Bug Components: general, persistence Affects Versions: 3.0.0-beta2 Reporter: Igor *Steps to reproduce:* # Multinode cluster (3 nodes) with arguments "-Xms4096m", "-Xmx4096m" # Create tables one by one up to 1000 *Expected:* 1000 tables are created. *Actual:* After 150+ tables the creation time is higher than 30 seconds. !image-2024-05-13-10-22-06-994.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22247) Handle 'partition cannot be started at Ignite node startup' situation
Roman Puchkovskiy created IGNITE-22247: -- Summary: Handle 'partition cannot be started at Ignite node startup' situation Key: IGNITE-22247 URL: https://issues.apache.org/jira/browse/IGNITE-22247 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22246) Write a test making sure that double-voting problem is not possible for volatile partitions
[ https://issues.apache.org/jira/browse/IGNITE-22246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22246: --- Description: IGNITE-16668 describes a design that is currently implemented in the PartitionReplicatorNodeRecovery class. This is needed to make sure that, when we restart an Ignite node having a volatile partition (which uses volatile Raft metastorage), and hence we break Raft assumptions about Raft metastorage being stored on a stable storage (i.e. its contents cannot be destroyed), we are still safe as the additional logic makes sure that the broken Raft assumptions do not cause any trouble. The trouble that can be caused is the 'double-vote' problem. The scenario follows: # Node A starts election and proposes itself as a candidate # Node C votes for node A # Node C restart and loses votedFor in its Raft metastorage # Node B starts election and proposes itself as a candidate (in the same term in thich node A proposed itself) # Node C votes for B (as it forgot that it already voted for A in this term) # Both nodes A and B get elected as leaders, so 'at most one leader at a term' property of Raft is broken Our test should try to get 2 leaders in the same term repeating this scenario. Probably, a lot of message cancellation/delaying will be needed (for example, to make sure that node B does not see node A self-proposals). > Write a test making sure that double-voting problem is not possible for > volatile partitions > --- > > Key: IGNITE-22246 > URL: https://issues.apache.org/jira/browse/IGNITE-22246 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > IGNITE-16668 describes a design that is currently implemented in the > PartitionReplicatorNodeRecovery class. This is needed to make sure that, when > we restart an Ignite node having a volatile partition (which uses volatile > Raft metastorage), and hence we break Raft assumptions about Raft metastorage > being stored on a stable storage (i.e. its contents cannot be destroyed), we > are still safe as the additional logic makes sure that the broken Raft > assumptions do not cause any trouble. > The trouble that can be caused is the 'double-vote' problem. The scenario > follows: > # Node A starts election and proposes itself as a candidate > # Node C votes for node A > # Node C restart and loses votedFor in its Raft metastorage > # Node B starts election and proposes itself as a candidate (in the same > term in thich node A proposed itself) > # Node C votes for B (as it forgot that it already voted for A in this term) > # Both nodes A and B get elected as leaders, so 'at most one leader at a > term' property of Raft is broken > Our test should try to get 2 leaders in the same term repeating this > scenario. Probably, a lot of message cancellation/delaying will be needed > (for example, to make sure that node B does not see node A self-proposals). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22215) Fix for ThinClientIndexQueryTest#testPageSize
[
https://issues.apache.org/jira/browse/IGNITE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846580#comment-17846580
]
Ignite TC Bot commented on IGNITE-22215:
{panel:title=Branch: [pull/11349/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11349/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=7868818buildTypeId=IgniteTests24Java8_RunAll]
> Fix for ThinClientIndexQueryTest#testPageSize
> -
>
> Key: IGNITE-22215
> URL: https://issues.apache.org/jira/browse/IGNITE-22215
> Project: Ignite
> Issue Type: Task
>Reporter: Oleg Valuyskiy
>Assignee: Oleg Valuyskiy
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in ThinClientIndexQueryTest#testPageSize where the 'reqs'
> collection is always empty as a wrong class is used for recording next page
> requests (GridQueryNextPageRequest instead of GridCacheQueryRequest).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22246) Write a test making sure that double-voting problem is not possible for volatile partitions
Roman Puchkovskiy created IGNITE-22246: -- Summary: Write a test making sure that double-voting problem is not possible for volatile partitions Key: IGNITE-22246 URL: https://issues.apache.org/jira/browse/IGNITE-22246 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22235) Remove eviction-related leftovers of AI2
[ https://issues.apache.org/jira/browse/IGNITE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Myskov reassigned IGNITE-22235: -- Assignee: Maksim Myskov > Remove eviction-related leftovers of AI2 > > > Key: IGNITE-22235 > URL: https://issues.apache.org/jira/browse/IGNITE-22235 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Myskov >Assignee: Maksim Myskov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > There is some code ported from AI2 but dead at the moment. The following > pieces are related to eviction and can be safely removed: > * org.apache.ignite.internal.pagememory.evict.PageEvictionTracker > * eviction-related configs in VolatilePageMemoryDataRegionConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21676) Sql. Move system view definitions to a separate package of a catalog module
[ https://issues.apache.org/jira/browse/IGNITE-21676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21676: - Assignee: Maksim Zhuravkov > Sql. Move system view definitions to a separate package of a catalog module > --- > > Key: IGNITE-21676 > URL: https://issues.apache.org/jira/browse/IGNITE-21676 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Let's move code related to system view definitions to a separate package, so > CatalogManagerImpl > only contains an implementation of SystemViewProvider interface/or a list of > a "imports" of system view definitions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22245) Write intents are not switched if primary changes
Kirill Sizov created IGNITE-22245: -- Summary: Write intents are not switched if primary changes Key: IGNITE-22245 URL: https://issues.apache.org/jira/browse/IGNITE-22245 Project: Ignite Issue Type: Bug Reporter: Kirill Sizov Assignee: Kirill Sizov If during the cleanup process the cleanup request fails to execute on an initially enlisted node the durable cleanup logic retries the cleanup request on the new partition primaries. Since the new primary node does not have in-memory transactional state, it skips write intent switch and reports successful cleanup. As a result we get a successfully completed transaction with write intents instead of real data in the storage. We had been covered with write intent resolution before vacuum was introduced. Now, if the state has been vacuumized, there is no chance to correctly resolve such write intents and we get corrupted data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22235) Remove eviction-related leftovers of AI2
[ https://issues.apache.org/jira/browse/IGNITE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22235: Fix Version/s: 3.0.0-beta2 > Remove eviction-related leftovers of AI2 > > > Key: IGNITE-22235 > URL: https://issues.apache.org/jira/browse/IGNITE-22235 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Myskov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > There is some code ported from AI2 but dead at the moment. The following > pieces are related to eviction and can be safely removed: > * org.apache.ignite.internal.pagememory.evict.PageEvictionTracker > * eviction-related configs in VolatilePageMemoryDataRegionConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22244) Incorrect error message for config show command
[ https://issues.apache.org/jira/browse/IGNITE-22244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-22244: --- Description: [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". same error for this command: node config show -u http://localhost:10300 was: [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". > Incorrect error message for config show command > --- > > Key: IGNITE-22244 > URL: https://issues.apache.org/jira/browse/IGNITE-22244 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > [defaultNode]> node config show sql > Unknown error > Conversion = '|' > The error should be like: no such config root "sql". > same error for this command: node config show -u http://localhost:10300 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22244) Incorrect error message for config show command
Aleksandr created IGNITE-22244: -- Summary: Incorrect error message for config show command Key: IGNITE-22244 URL: https://issues.apache.org/jira/browse/IGNITE-22244 Project: Ignite Issue Type: Bug Components: cli Reporter: Aleksandr [defaultNode]> node config show sql Unknown error Conversion = '|' The error should be like: no such config root "sql". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844600#comment-17844600
]
Pavel Pereslegin edited comment on IGNITE-22061 at 5/15/24 9:04 AM:
The easiest way is to use {{stripTrailingZeros}} (similar to what is done in
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up
with a more efficient estimation (or at least not call {{stripTrailingZeros}}
twice).
was (Author: xtern):
The easiest way is to use {{stripTrailingZeros}} (similar to what is done in
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up
with a more efficient estimation.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16520) Refactor IgniteCliInterfaceTest
[ https://issues.apache.org/jira/browse/IGNITE-16520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-16520: - Assignee: Vadim Pakhnushev > Refactor IgniteCliInterfaceTest > --- > > Key: IGNITE-16520 > URL: https://issues.apache.org/jira/browse/IGNITE-16520 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Roman Puchkovskiy >Assignee: Vadim Pakhnushev >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCliInterfaceTest is already pretty long and it will become even longer > when we add more commands. It makes sense to pull the test classes (like > Config, Node, etc) to the upper level and make them independent from each > other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22208) Deduplicate DEFAULT_SCHEMA_NAME
[
https://issues.apache.org/jira/browse/IGNITE-22208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846547#comment-17846547
]
Igor Sapego commented on IGNITE-22208:
--
Looks good to me.
> Deduplicate DEFAULT_SCHEMA_NAME
> ---
>
> Key: IGNITE-22208
> URL: https://issues.apache.org/jira/browse/IGNITE-22208
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following constant is duplicated 6 times currently:
> {code:java}
> DEFAULT_SCHEMA_NAME = "PUBLIC"
> {code}
> * Let's put it somewhere in the core module and reuse.
> * It should *not* be a part of the public API. For internal use only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21809) Sql. Improve intra-query parallelism
[ https://issues.apache.org/jira/browse/IGNITE-21809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-21809: Description: At the moment, intra-query parallelism is achieved by splitting the query on several fragments in the place where distribution conversion is required, but the fragment itself is tied up to a single thread. Such a parallelization results in a low resource utilization by a single query, especially in case of huge fragments like the ones containing aggregation or colocated joins. Let's investigate possible solutions and make a POC was:At the moment, intra-query parallelism is achieved by splitting the query on several fragments in the place where distribution conversion is required, but the fragment itself is tied up to a single thread. Such a parallelization results in a low resource utilization by a single query, especially in case of huge fragments like the ones containing aggregation or colocated joins. > Sql. Improve intra-query parallelism > > > Key: IGNITE-21809 > URL: https://issues.apache.org/jira/browse/IGNITE-21809 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > At the moment, intra-query parallelism is achieved by splitting the query on > several fragments in the place where distribution conversion is required, but > the fragment itself is tied up to a single thread. Such a parallelization > results in a low resource utilization by a single query, especially in case > of huge fragments like the ones containing aggregation or colocated joins. > Let's investigate possible solutions and make a POC -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846523#comment-17846523
]
Evgeny Stanilovsky commented on IGNITE-19331:
-
i investigate a bit more and seems we can remove test_boolean_cast.test_ignore
cause it`s irrelevant with cast matrix from 6.22 standard chapter, [~jooger]
wdyt ?
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22183) Adding events recording for Index Queries
[
https://issues.apache.org/jira/browse/IGNITE-22183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846521#comment-17846521
]
Ignite TC Bot commented on IGNITE-22183:
{panel:title=Branch: [pull/11342/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11342/head] Base: [master] : New Tests
(19)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
9|https://ci2.ignite.apache.org/viewLog.html?buildId=7858440]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedSnapshotEnabledQuerySelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedQueryP2PDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedQueryP2PDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCachePartitionedQueryEvtsDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCacheAtomicQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteCacheAtomicNearEnabledQuerySelfTest.testIndexQueryEvents - PASSED{color}
{color:#8b}Queries 1 (lazy=true){color} [[tests
9|https://ci2.ignite.apache.org/viewLog.html?buildId=7858441]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCacheReplicatedQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCacheReplicatedQueryP2PDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCachePartitionedSnapshotEnabledQuerySelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCacheAtomicQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCachePartitionedQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCachePartitionedQueryEvtsDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCacheAtomicNearEnabledQuerySelfTest.testIndexQueryEvents - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteCachePartitionedQueryP2PDisabledSelfTest.testIndexQueryEvents -
PASSED{color}
{color:#8b}ZooKeeper (Discovery) 4{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7858466]]
* {color:#013220}ZookeeperDiscoverySpiTestSuite4:
IgniteCacheReplicatedQuerySelfTest.testIndexQueryEvents - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7858473buildTypeId=IgniteTests24Java8_RunAll]
> Adding events recording for Index Queries
> -
>
> Key: IGNITE-22183
> URL: https://issues.apache.org/jira/browse/IGNITE-22183
> Project: Ignite
> Issue Type: Task
>Reporter: Oleg Valuyskiy
>Assignee: Oleg Valuyskiy
>Priority: Minor
> Labels: ise
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Recording of Cache Query Read Object events and Cache Query Execution events
> need to be added for Index Queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846517#comment-17846517
]
Evgeny Stanilovsky commented on IGNITE-19331:
-
such casts are not possible in different DB, also standard forbid such casts,
seems we need to delete this expression and move forward, wdyt ?
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19331) Sql. CAST with Boolean operations is failed.
[
https://issues.apache.org/jira/browse/IGNITE-19331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19331:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. CAST with Boolean operations is failed.
>
>
> Key: IGNITE-19331
> URL: https://issues.apache.org/jira/browse/IGNITE-19331
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> SqlRunner tests are failed
> {noformat}
> /sql/test_boolean_cast.test_ignore
> {noformat}
> {noformat}
> query T
> SELECT CAST(CAST('1' AS float) AS BOOLEAN)
>
> true
> {noformat}
> {noformat}
> Not expected result at: (test_try_cast.test:150). [row=0, col=0,
> expected=true, actual=false]
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkEquals(SqlScriptRunner.java:635)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResultTuples(SqlScriptRunner.java:604)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.checkResult(SqlScriptRunner.java:583)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:555)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22243) Flaky test testInternalRootConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-22243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22243:
Description:
Test is flaky [1] on main branch:
ConfigurationTreeGeneratorTest#testInternalRootConfiguration
{noformat}
org.opentest4j.AssertionFailedError: expected:
but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertSame.failNotSame(AssertSame.java:50)
at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:35)
at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:30)
at app//org.junit.jupiter.api.Assertions.assertSame(Assertions.java:2860)
at
app//org.apache.ignite.internal.configuration.asm.ConfigurationTreeGeneratorTest.testInternalRootConfiguration(ConfigurationTreeGeneratorTest.java:162)
{noformat}
[1]
https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual=true
was:
Test is flaky [1] on main branch:
ConfigurationTreeGeneratorTest#testInternalRootConfiguration
[1]
https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual=true
> Flaky test testInternalRootConfiguration
>
>
> Key: IGNITE-22243
> URL: https://issues.apache.org/jira/browse/IGNITE-22243
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Test is flaky [1] on main branch:
> ConfigurationTreeGeneratorTest#testInternalRootConfiguration
> {noformat}
> org.opentest4j.AssertionFailedError: expected:
> but was:
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertSame.failNotSame(AssertSame.java:50)
> at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:35)
> at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:30)
> at app//org.junit.jupiter.api.Assertions.assertSame(Assertions.java:2860)
> at
> app//org.apache.ignite.internal.configuration.asm.ConfigurationTreeGeneratorTest.testInternalRootConfiguration(ConfigurationTreeGeneratorTest.java:162)
> {noformat}
> [1]
> https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22243) Flaky test testInternalRootConfiguration
Evgeny Stanilovsky created IGNITE-22243: --- Summary: Flaky test testInternalRootConfiguration Key: IGNITE-22243 URL: https://issues.apache.org/jira/browse/IGNITE-22243 Project: Ignite Issue Type: Bug Components: general Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Test is flaky [1] on main branch: ConfigurationTreeGeneratorTest#testInternalRootConfiguration [1] https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
