[jira] [Updated] (IGNITE-21710) ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes fails with Could not wait for the replica readiness due to timeout [replicaGroupId=7_part_0, req=Read
[
https://issues.apache.org/jira/browse/IGNITE-21710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21710:
-
Description:
[https://ci.ignite.apache.org/viewLog.html?buildId=7915182&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&fromSakuraUI=true]
{code:java}
org.apache.ignite.sql.SqlException: IGN-REP-3
TraceId:49b8d03e-aa13-43e0-8f3e-a495084a9221 Could not wait for the replica
readiness due to timeout [replicaGroupId=7_part_0,
req=ReadWriteSingleRowReplicaRequestImpl]
at
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
at
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
at
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.sql(ClusterPerClassIntegrationTest.java:368)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.lambda$sql$4(ClusterPerClassIntegrationTest.java:388)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.executeAwaitingIndexes(ClusterPerClassIntegrationTest.java:467)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.sql(ClusterPerClassIntegrationTest.java:388)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.sql(ClusterPerClassIntegrationTest.java:379)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.sql(ClusterPerClassIntegrationTest.java:375)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.insertDataInTransaction(ClusterPerClassIntegrationTest.java:343)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.insertData(ClusterPerClassIntegrationTest.java:333)
at
app//org.apache.ignite.internal.ClusterPerClassIntegrationTest.insertPeople(ClusterPerClassIntegrationTest.java:258)
at
app//org.apache.ignite.internal.index.ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes(ItIndexAndRebalanceTest.java:56)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
at java.base@11.0.17/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base@11.0.17/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: java.util.concurrent.CompletionException:
org.apache.ignite.sql.SqlException: IGN-REP-3
TraceId:49b8d03e-aa13-43e0-8f3e-a495084a9221 Could not wait for the replica
readiness due to timeout [replicaGroupId=7_part_0,
req=ReadWriteSingleRowReplicaRequestImpl]
at
org.apache.ignite.internal.sql.api.SessionImpl.lambda$executeAsync$3(SessionImpl.java:264)
at
java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
at
java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.sql.engine.SqlQueryProcessor$PrefetchCallback.onPrefetchComplete(SqlQueryProcessor.java:1028)
at
org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$3(KeyValueModifyPlan.java:141)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:320)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:85)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.ignite.sql.SqlException: IGN-REP-3
TraceId:49b8d03e-aa13-43e0-8f3e-a495084a9221 Could not wait for the replica
readiness due to timeout [replicaGroupId=7_part_0,
req=ReadWriteSingleRowReplicaRequestImpl]
at
[jira] [Updated] (IGNITE-21742) Refactor creating and managing of Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Summary: Refactor creating and managing of Page Memory Indexes (was:
Refactor creating and managing Page Memory Indexes )
> Refactor creating and managing of Page Memory Indexes
> --
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Epic Link: IGNITE-20782
Reviewer: Kirill Tkalenko
> Refactor creating and managing Page Memory Indexes
> ---
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Description: Current logic of managing Page Memory indexes (like recovery,
creation of new indexes and updates during rebalance) is all contained within
the {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to
modify it (like, for example when implementing recovery in IGNITE-21671). Also,
current approach of creating or restoring Index Trees is not very convenient as
it relies on a boolean flag passed to the corresponding constructor. It would
be more readable and maintainable to have distinct factory methods for that.
> Refactor creating and managing Page Memory Indexes
> ---
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
Aleksandr Polovtcev created IGNITE-21742: Summary: Refactor creating and managing Page Memory Indexes Key: IGNITE-21742 URL: https://issues.apache.org/jira/browse/IGNITE-21742 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21741) Remove experimental flag from --meta command
YuJue Li created IGNITE-21741: - Summary: Remove experimental flag from --meta command Key: IGNITE-21741 URL: https://issues.apache.org/jira/browse/IGNITE-21741 Project: Ignite Issue Type: Improvement Components: control.sh Affects Versions: 2.16 Reporter: YuJue Li Assignee: YuJue Li Fix For: 2.17 The Control Script has a --meta command, which developed in the following ticket: https://issues.apache.org/jira/browse/IGNITE-13154 The official document does not provide an introduction to this feature, and due to the "experimental", there is no output in the command line help, so almost no users are aware of this feature. This feature is very useful in some scenarios. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21740) Fix catalog dsl according to the storage profiles feature
[ https://issues.apache.org/jira/browse/IGNITE-21740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21740: Summary: Fix catalog dsl according to the storage profiles feature (was: Fix catalog dsl according to storage profiles feature) > Fix catalog dsl according to the storage profiles feature > - > > Key: IGNITE-21740 > URL: https://issues.apache.org/jira/browse/IGNITE-21740 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > *Motivation* > New catalog-dsl module from IGNITE-21597 built around the old concept: zone > has engine option and has no mandatory storage_profiles field > *Definition of done* > * Engine removed from zone definition > * Storage profiles added as an mandatory field to definition -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21740) Fix catalog dsl according to storage profiles feature
[ https://issues.apache.org/jira/browse/IGNITE-21740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21740: Epic Link: IGNITE-19170 > Fix catalog dsl according to storage profiles feature > - > > Key: IGNITE-21740 > URL: https://issues.apache.org/jira/browse/IGNITE-21740 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > New catalog-dsl module from IGNITE-21597 built around the old concept: zone > has engine option and has no mandatory storage_profiles field > *Definition of done* > * Engine removed from zone definition > * Storage profiles added as an mandatory field to definition -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21740) Fix catalog dsl according to storage profiles feature
[ https://issues.apache.org/jira/browse/IGNITE-21740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21740: Description: *Motivation* New catalog-dsl module from IGNITE-21597 built around the old concept: zone has engine option and has no mandatory storage_profiles field *Definition of done* * Engine removed from zone definition * Storage profiles added as an mandatory field to definition > Fix catalog dsl according to storage profiles feature > - > > Key: IGNITE-21740 > URL: https://issues.apache.org/jira/browse/IGNITE-21740 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > New catalog-dsl module from IGNITE-21597 built around the old concept: zone > has engine option and has no mandatory storage_profiles field > *Definition of done* > * Engine removed from zone definition > * Storage profiles added as an mandatory field to definition -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21740) Fix catalog dsl according to storage profiles feature
Kirill Gusakov created IGNITE-21740: --- Summary: Fix catalog dsl according to storage profiles feature Key: IGNITE-21740 URL: https://issues.apache.org/jira/browse/IGNITE-21740 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Affects Version/s: 3.0.0-beta2
> JDBC connection to a multi-node cluster doesn't take into account
> clientConnector.port from each node
> -
>
> Key: IGNITE-21739
> URL: https://issues.apache.org/jira/browse/IGNITE-21739
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.0.0-beta2
> Environment: * multi-node cluster
> * different `{{{}clientConnector.port{}}}` on each cluster node
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
> Attachments: exception.log
>
>
> *WHEN* you create a multi-node cluster
> *AND* specify different {color:#de350b}{{clientConnector.port}}{color} on
> each cluster node
> (for example,
> node1 (172.24.1.2) - {color:#de350b}{{clientConnector.port=10800}}{color}
> node2 (172.24.1.3) - {color:#de350b}{{clientConnector.port=10801}}{color}
> node3 (172.24.1.4) - {color:#de350b}{{clientConnector.port=10802}}{color})
> *AND* connect to cluster like
> {color:#de350b}{{{}jdbc:ignite:thin://{node1address{{color} (for example,
> {{{color:#de350b}jdbc:ignite:thin://172.24.1.2{color})}}
> *AND* try to insert a couple of records
> *THEN* you will get an error like
> {code:java}
> Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger
> warnWARNING: Failed to establish connection to 172.24.1.3:10800:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information:
> /172.24.1.3:10800java.util.concurrent.CompletionException:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800 at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
>at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
> at
> io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
> at
> io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
> at
> io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)Caused by:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
> ... 17 moreCaused by:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /172.24.1.3:10800Caused by:
> java.net.ConnectException: Connection
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Labels: ignite-3 (was: )
> JDBC connection to a multi-node cluster doesn't take into account
> clientConnector.port from each node
> -
>
> Key: IGNITE-21739
> URL: https://issues.apache.org/jira/browse/IGNITE-21739
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
> Environment: * multi-node cluster
> * different `{{{}clientConnector.port{}}}` on each cluster node
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3
> Attachments: exception.log
>
>
> *WHEN* you create a multi-node cluster
> *AND* specify different {color:#de350b}{{clientConnector.port}}{color} on
> each cluster node
> (for example,
> node1 (172.24.1.2) - {color:#de350b}{{clientConnector.port=10800}}{color}
> node2 (172.24.1.3) - {color:#de350b}{{clientConnector.port=10801}}{color}
> node3 (172.24.1.4) - {color:#de350b}{{clientConnector.port=10802}}{color})
> *AND* connect to cluster like
> {color:#de350b}{{{}jdbc:ignite:thin://{node1address{{color} (for example,
> {{{color:#de350b}jdbc:ignite:thin://172.24.1.2{color})}}
> *AND* try to insert a couple of records
> *THEN* you will get an error like
> {code:java}
> Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger
> warnWARNING: Failed to establish connection to 172.24.1.3:10800:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information:
> /172.24.1.3:10800java.util.concurrent.CompletionException:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800 at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
>at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
> at
> io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
> at
> io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
> at
> io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)Caused by:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
> ... 17 moreCaused by:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /172.24.1.3:10800Caused by:
> java.net.ConnectException: Connection refused: no further information at
> j
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Attachment: exception.log
> JDBC connection to a multi-node cluster doesn't take into account
> clientConnector.port from each node
> -
>
> Key: IGNITE-21739
> URL: https://issues.apache.org/jira/browse/IGNITE-21739
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
> Environment: * multi-node cluster
> * different `{{{}clientConnector.port{}}}` on each cluster node
>Reporter: Nikita Sivkov
>Priority: Major
> Attachments: exception.log
>
>
> *WHEN* you create a multi-node cluster
> *AND* specify different {color:#de350b}{{clientConnector.port}}{color} on
> each cluster node
> (for example,
> node1 (172.24.1.2) - {color:#de350b}{{clientConnector.port=10800}}{color}
> node2 (172.24.1.3) - {color:#de350b}{{clientConnector.port=10801}}{color}
> node3 (172.24.1.4) - {color:#de350b}{{clientConnector.port=10802}}{color})
> *AND* connect to cluster like
> {color:#de350b}{{{}jdbc:ignite:thin://{node1address{{color} (for example,
> {{{color:#de350b}jdbc:ignite:thin://172.24.1.2{color})}}
> *AND* try to insert a couple of records
> *THEN* you will get an error like
> {code:java}
> Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger
> warnWARNING: Failed to establish connection to 172.24.1.3:10800:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information:
> /172.24.1.3:10800java.util.concurrent.CompletionException:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800 at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
>at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
> at
> io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
> at
> io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
> at
> io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)Caused by:
> org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
> TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
> Connection refused: no further information: /172.24.1.3:10800at
> org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
> ... 17 moreCaused by:
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /172.24.1.3:10800Caused by:
> java.net.ConnectException: Connection refused: no further information at
> java.base/sun.nio.ch.SocketChanne
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Description:
*WHEN* you create a multi-node cluster
*AND* specify different {color:#de350b}{{clientConnector.port}}{color} on each
cluster node
(for example,
node1 (172.24.1.2) - {color:#de350b}{{clientConnector.port=10800}}{color}
node2 (172.24.1.3) - {color:#de350b}{{clientConnector.port=10801}}{color}
node3 (172.24.1.4) - {color:#de350b}{{clientConnector.port=10802}}{color})
*AND* connect to cluster like
{color:#de350b}{{{}jdbc:ignite:thin://{node1address{{color} (for example,
{{{color:#de350b}jdbc:ignite:thin://172.24.1.2{color})}}
*AND* try to insert a couple of records
*THEN* you will get an error like
{code:java}
Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger
warnWARNING: Failed to establish connection to 172.24.1.3:10800:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information:
/172.24.1.3:10800java.util.concurrent.CompletionException:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
at
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
at
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
at
io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636) at
io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629) at
io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118) at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)Caused by:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
... 17 moreCaused by:
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
no further information: /172.24.1.3:10800Caused by: java.net.ConnectException:
Connection refused: no further information at
java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at
java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779)
at
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:335)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.Thread
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[ https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Sivkov updated IGNITE-21739: --- Description: Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger warn WARNING: Failed to establish connection to 172.24.1.3:10800: org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect: Connection refused: no further information: /172.24.1.3:10800 java.util.concurrent.CompletionException: org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect: Connection refused: no further information: /172.24.1.3:10800 at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331) at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346) at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063) at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) at org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197) at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590) at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583) at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559) at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492) at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636) at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629) at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect: Connection refused: no further information: /172.24.1.3:10800 at org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194) ... 17 more Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: /172.24.1.3:10800 Caused by: java.net.ConnectException: Connection refused: no further information at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:335) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834) Mar 12, 2024 7:37:21 PM org.apache.ignite.internal.logger.IgniteLogger warn WARNING: Failed to establish connection to 172.24.1.4:10800: org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1 TraceId:d7d08ee0-64f6-45ea-872f-1c2adb8d128a Client failed to connect: Connection refused: no further information: /172.24.1.4:10800 java.util.concurrent.CompletionException: org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1 TraceId:d7d08ee0-64f6-45ea-872f-1c2adb8d128a Client failed to connect: Connection refused: no
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Description:
*WHEN* you create a multi-node cluster
*AND* specify different {{clientConnector.port}} on each cluster node
(for example,
node1 - 172.24.1.2 - {{clientConnector.port=10800}}
node2 - 172.24.1.3 - {{clientConnector.port=10801}}
node3 - 172.24.1.4 - {{{}clientConnector.port=10802{}}})
*AND* connect to cluster like {{{}jdbc:ignite:thin://{node1address{ (for
example, {{jdbc:ignite:thin://172.24.1.2)}}
*AND* try to insert a couple of records
*THEN* you will get an error like
{code:java}
WARNING: Failed to establish connection to 172.24.1.3:10800:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
java.util.concurrent.CompletionException:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
at
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
at
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
at
io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
at
io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
at
io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.ignite.client.IgniteClientConnectionException:
IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to
connect: Connection refused: no further information: /172.24.1.3:10800
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
... 17 more
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException:
Connection refused: no further information: /172.24.1.3:10800
Caused by: java.net.ConnectException: Connection refused: no further information
at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779)
at
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:335)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.r
[jira] [Updated] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
[
https://issues.apache.org/jira/browse/IGNITE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-21739:
---
Description:
*WHEN* you create a multi-node cluster
*AND* specify different {{clientConnector.port}} on each cluster node
(for example,
node1 - {{clientConnector.port=10800}}
node2 - {{clientConnector.port=10801}}
node3 - {{{}clientConnector.port=10802{}}})
*AND* connect to cluster like {{jdbc:ignite:thin://\{node1address}}}
*AND* try to insert a couple of records
*THEN* you will get an error like
{code:java}
WARNING: Failed to establish connection to 172.24.1.3:10800:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
java.util.concurrent.CompletionException:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
at
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
at
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
at
io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
at
io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
at
io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.ignite.client.IgniteClientConnectionException:
IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to
connect: Connection refused: no further information: /172.24.1.3:10800
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
... 17 more
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException:
Connection refused: no further information: /172.24.1.3:10800
Caused by: java.net.ConnectException: Connection refused: no further information
at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779)
at
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:335)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834) {code}
was:
*Issue:*
WHEN you create a multi-node cluster
AND spec
[jira] [Created] (IGNITE-21739) JDBC connection to a multi-node cluster doesn't take into account clientConnector.port from each node
Nikita Sivkov created IGNITE-21739:
--
Summary: JDBC connection to a multi-node cluster doesn't take into
account clientConnector.port from each node
Key: IGNITE-21739
URL: https://issues.apache.org/jira/browse/IGNITE-21739
Project: Ignite
Issue Type: Bug
Components: jdbc
Environment: * multi-node cluster
* different `{{{}clientConnector.port{}}}` on each cluster node
Reporter: Nikita Sivkov
*Issue:*
WHEN you create a multi-node cluster
AND specify different `{{{}clientConnector.port{}}}` on each cluster node
(for example,
node1 - `{{{}clientConnector.port=10800{}}}`
node2 - `{{{}clientConnector.port=10801{}}}`
node3 - `{{{}clientConnector.port=10802{}}}`)
AND connect to cluster like `{{{}jdbc:ignite:thin://\{node1address}{}}}`
AND try to insert a couple of records
THEN you will get an error like
```
WARNING: Failed to establish connection to 172.24.1.3:10800:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
java.util.concurrent.CompletionException:
org.apache.ignite.client.IgniteClientConnectionException: IGN-CLIENT-1
TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to connect:
Connection refused: no further information: /172.24.1.3:10800
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1063)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:197)
at
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
at
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
at
io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
at
io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
at
io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:322)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:338)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.ignite.client.IgniteClientConnectionException:
IGN-CLIENT-1 TraceId:df21d718-d40c-4506-84e7-6ec141de9ab5 Client failed to
connect: Connection refused: no further information: /172.24.1.3:10800
at
org.apache.ignite.internal.client.io.netty.NettyClientConnectionMultiplexer.lambda$openAsync$1(NettyClientConnectionMultiplexer.java:194)
... 17 more
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException:
Connection refused: no further information: /172.24.1.3:10800
Caused by: java.net.ConnectException: Connection refused: no further information
at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779)
at
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337)
at
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:335)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(Singl
[jira] [Commented] (IGNITE-21641) OOM in PartitionReplicaListenerTest
[
https://issues.apache.org/jira/browse/IGNITE-21641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825747#comment-17825747
]
Vladislav Pyatkov commented on IGNITE-21641:
Merged 02f5682181e82d87c1fddc157edbb6475ebf818b
> OOM in PartitionReplicaListenerTest
> ---
>
> Key: IGNITE-21641
> URL: https://issues.apache.org/jira/browse/IGNITE-21641
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-03-01-12-22-32-053.png,
> image-2024-03-01-20-36-08-577.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> TC run failed with OOM
> Problem occurred after
> PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite run,
> {noformat}
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true
> [2024-03-01T05:12:50,629][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469368142283
> [2024-03-01T05:12:50,638][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Stopping test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [14] true, true, false, true, cost: 8ms.
> [05:12:50] : [testReadOnlyGetAfterRowRewrite(boolean,
> boolean, boolean, boolean)]
> org.apache.ignite.internal.table.distributed.replication.PartitionReplicaListenerTest.testReadOnlyGetAfterRowRewrite([15]
> true, true, true, false) (10m:22s)
> [05:12:50] : [:ignite-table:test] PartitionReplicaListenerTest >
> testReadOnlyGetAfterRowRewrite(boolean, boolean, boolean, boolean) > [15]
> true, true, true, false STANDARD_OUT
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> >>> Starting test:
> PartitionReplicaListenerTest#testReadOnlyGetAfterRowRewrite, displayName:
> [15] true, true, true, false
> [05:12:50] : [:ignite-table:test]
> [2024-03-01T05:12:50,648][INFO ][Test worker][PartitionReplicaListenerTest]
> workDir:
> build/work/PartitionReplicaListenerTest/testReadOnlyGetAfterRowRewrite_33496469386328241
> [05:18:42] : [:ignite-table:test] java.lang.OutOfMemoryError: Java
> heap space
> [05:18:42] : [:ignite-table:test] Dumping heap to
> java_pid2349600.hprof ...
> [05:19:06] : [:ignite-table:test] Heap dump file created
> [3645526743 bytes in 24.038 secs]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7898564?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false
> After analysing heap dump it appears that the reason of OOM is a problem with
> Mockito.
> !image-2024-03-01-12-22-32-053.png!
> We need to investigate the reason of a problem with Mockito
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21348) Trigger the lease negotiation retry in case when the lease candidate is no more contained in assignments
[ https://issues.apache.org/jira/browse/IGNITE-21348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-21348: -- Reviewer: Vladislav Pyatkov > Trigger the lease negotiation retry in case when the lease candidate is no > more contained in assignments > > > Key: IGNITE-21348 > URL: https://issues.apache.org/jira/browse/IGNITE-21348 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > On receiving the "lease granted" message, the candidate replica tries to > catch up the actual storage state, in order to do that it makes read index > request. But in case when this candidate is no more a member of assignments > (and replication group) this request fails and is retried until the lease > negotiation interval exceeds. This makes no sense because such retries will > not be successful, and the current candidate is not a good candidate anymore > - because, although the leaseholder may be not a part of replication group, > preferably it should be, and should be its leader. > The assignment changes when some of current candidates and leaseholders are > no more included in new assignment set, should be detected on the placement > driver active actor, and the current lease should be revoked (if negotiation > is in progress) or not prolonged. The new negotitation will be triggered > automatically by the lease updater. > *Implementation notes* > This assignment changes detection should be done on placement driver side, > because the events of assignment changes can be processed on different nodes > in different time, and there is already assignments tracker as a part of > placement driver. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21738) Resolve potential races when table is destroying
Andrey Mashenkov created IGNITE-21738: - Summary: Resolve potential races when table is destroying Key: IGNITE-21738 URL: https://issues.apache.org/jira/browse/IGNITE-21738 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov After IGNITE-21585 there are potential races: 1. ClientPrimaryReplicaTracker may update `primaryReplicas` after table destroyed concurrently. 2. TableManager may register index (see `registerIndexesToTable`) in a table, while LWM rising up concurrently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21709) Revise TimestampAware messages processing
[
https://issues.apache.org/jira/browse/IGNITE-21709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21709:
--
Description:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is necessary to adjust the clock when processing
{{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
each component must duplicate the clock adjusting logic.
*Also* as part of this task it would be nice to fix the behavior of SQL so that
it does NOT update the clock for READ ONLY operations (in
{{MessageServiceImpl#onMessage}}).
was:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is necessary to adjust the clock when processing
{{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
each component must duplicate the clock adjusting logic.
*Also* as part of this task it would be nice to fix the behavior of SQL so that
it does NOT update the clock for READ ONLY operations.
> Revise TimestampAware messages processing
> -
>
> Key: IGNITE-21709
> URL: https://issues.apache.org/jira/browse/IGNITE-21709
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid
> logical clock.
> Currently, ReplicaManager updates the local clock when it receives a
> {{ReplicaRequest}} with a timestamp.
> It may be worth revising the design and adding general processing of such
> messages (probably at the {{MessagingService}} level).
> For example, it is necessary to adjust the clock when processing
> {{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
> each component must duplicate the clock adjusting logic.
> *Also* as part of this task it would be nice to fix the behavior of SQL so
> that it does NOT update the clock for READ ONLY operations (in
> {{MessageServiceImpl#onMessage}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21709) Revise TimestampAware messages processing
[
https://issues.apache.org/jira/browse/IGNITE-21709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21709:
--
Description:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is necessary to adjust the clock when processing
{{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
each component must duplicate the clock adjusting logic.
*Also* as part of this task it would be nice to fix the behavior of SQL so that
it does NOT update the clock for READ ONLY operations.
was:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is necessary to adjust the clock when processing
{{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
each component must duplicate the clock adjusting logic.
*Also* as part of this task it would be nice to fix the behavior of sql-engine
so that it does NOT update the clock for READ ONLY operations.
> Revise TimestampAware messages processing
> -
>
> Key: IGNITE-21709
> URL: https://issues.apache.org/jira/browse/IGNITE-21709
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid
> logical clock.
> Currently, ReplicaManager updates the local clock when it receives a
> {{ReplicaRequest}} with a timestamp.
> It may be worth revising the design and adding general processing of such
> messages (probably at the {{MessagingService}} level).
> For example, it is necessary to adjust the clock when processing
> {{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
> each component must duplicate the clock adjusting logic.
> *Also* as part of this task it would be nice to fix the behavior of SQL so
> that it does NOT update the clock for READ ONLY operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21737) Server node failure in case of nodes join and leave a cluster with a security is enabled
[
https://issues.apache.org/jira/browse/IGNITE-21737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay updated IGNITE-21737:
-
Description:
Server node ({_}{_}) fails
with such an error
{code:java}
JVM will be halted immediately due to the failure: [failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to
find security context for subject with given ID]{code}
when an arbitrary client node leaves a topology and a new one joins it. We host
thick client nodes in k8, so this error occurs when we simply restart one pod.
One assumption - a pretty big ring of around 40 nodes (5 servers, 35 clients)
prevents somehow to find a security context of disconnected node.
Each disconnected node uses a graceful shutdown timeout:
{code:java}
public void onLifecycleEvent(LifecycleEventType evt) {
if (evt == LifecycleEventType.BEFORE_NODE_STOP) {
Thread.sleep(40_000);
}
} {code}
was:
Server node () fails with
such an error
JVM will be halted immediately due to the failure: [failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to
find security context for subject with given ID]
when an arbitrary client node leaves a topology and a new one joins it. We host
thick client nodes in k8, so this error occurs when we simply restart one pod.
One assumption -
a pretty big ring of around 40 nodes prevents somehow to find a security
context of disconnected node.
> Server node failure in case of nodes join and leave a cluster with a security
> is enabled
>
>
> Key: IGNITE-21737
> URL: https://issues.apache.org/jira/browse/IGNITE-21737
> Project: Ignite
> Issue Type: Bug
> Components: security
>Affects Versions: 2.16
>Reporter: Nikolay
>Priority: Major
>
> Server node ({_}{_})
> fails with such an error
> {code:java}
> JVM will be halted immediately due to the failure: [failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID]{code}
> when an arbitrary client node leaves a topology and a new one joins it. We
> host thick client nodes in k8, so this error occurs when we simply restart
> one pod.
> One assumption - a pretty big ring of around 40 nodes (5 servers, 35 clients)
> prevents somehow to find a security context of disconnected node.
> Each disconnected node uses a graceful shutdown timeout:
> {code:java}
> public void onLifecycleEvent(LifecycleEventType evt) {
> if (evt == LifecycleEventType.BEFORE_NODE_STOP) {
> Thread.sleep(40_000);
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21737) Server node failure in case of nodes join and leave a cluster with a security is enabled
Nikolay created IGNITE-21737: Summary: Server node failure in case of nodes join and leave a cluster with a security is enabled Key: IGNITE-21737 URL: https://issues.apache.org/jira/browse/IGNITE-21737 Project: Ignite Issue Type: Bug Components: security Affects Versions: 2.16 Reporter: Nikolay Server node () fails with such an error JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to find security context for subject with given ID] when an arbitrary client node leaves a topology and a new one joins it. We host thick client nodes in k8, so this error occurs when we simply restart one pod. One assumption - a pretty big ring of around 40 nodes prevents somehow to find a security context of disconnected node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21709) Revise TimestampAware messages processing
[
https://issues.apache.org/jira/browse/IGNITE-21709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21709:
--
Description:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is necessary to adjust the clock when processing
{{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
each component must duplicate the clock adjusting logic.
*Also* as part of this task it would be nice to fix the behavior of sql-engine
so that it does NOT update the clock for READ ONLY operations.
was:
{{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid logical
clock.
Currently, ReplicaManager updates the local clock when it receives a
{{ReplicaRequest}} with a timestamp.
It may be worth revising the design and adding general processing of such
messages (probably at the {{MessagingService}} level).
For example, it is also necessary to adjust the clock when receiving a
{{QueryBatchMessage}} (sql-engine) and currently each component must duplicate
the clock adjusting logic.
> Revise TimestampAware messages processing
> -
>
> Key: IGNITE-21709
> URL: https://issues.apache.org/jira/browse/IGNITE-21709
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TimestampAware}} messages contain hybrid timestamp to adjust a hybrid
> logical clock.
> Currently, ReplicaManager updates the local clock when it receives a
> {{ReplicaRequest}} with a timestamp.
> It may be worth revising the design and adding general processing of such
> messages (probably at the {{MessagingService}} level).
> For example, it is necessary to adjust the clock when processing
> {{TimestampAware}} messages in sql-engine's {{MessageService}}. so currently
> each component must duplicate the clock adjusting logic.
> *Also* as part of this task it would be nice to fix the behavior of
> sql-engine so that it does NOT update the clock for READ ONLY operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations with impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Fix Version/s: (was: 3.0.0-beta2)
> Sql. Do not perform index operations with impossible search conditions for
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 to eliminate
> all results
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations with impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Epic Link: IGNITE-19479
> Sql. Do not perform index operations with impossible search conditions for
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 to eliminate
> all results
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21514) Deal with index destruction on compaction of catalog during a full state transfer
[ https://issues.apache.org/jira/browse/IGNITE-21514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21514: Assignee: Kirill Tkalenko > Deal with index destruction on compaction of catalog during a full state > transfer > - > > Key: IGNITE-21514 > URL: https://issues.apache.org/jira/browse/IGNITE-21514 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > This is the part of IGNITE-18595 in which we will need to deal with the > destruction of indexes on catalog compaction during a full state transfer. > The way I see it, we will simply need to get rid of read-only indexes for > which some special exception will occur (for example, > *StorageDestroyedException*) and no longer use such an index in a full state > transfer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21514) Deal with index destruction on compaction of catalog during a full state transfer
[ https://issues.apache.org/jira/browse/IGNITE-21514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21514: - Fix Version/s: 3.0.0-beta2 > Deal with index destruction on compaction of catalog during a full state > transfer > - > > Key: IGNITE-21514 > URL: https://issues.apache.org/jira/browse/IGNITE-21514 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > This is the part of IGNITE-18595 in which we will need to deal with the > destruction of indexes on catalog compaction during a full state transfer. > The way I see it, we will simply need to get rid of read-only indexes for > which some special exception will occur (for example, > *StorageDestroyedException*) and no longer use such an index in a full state > transfer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21707) Update openapi-generator
[ https://issues.apache.org/jira/browse/IGNITE-21707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21707: - Labels: ignite-3 ignite-3-cli-tool (was: ignite-3-cli-tool) > Update openapi-generator > > > Key: IGNITE-21707 > URL: https://issues.apache.org/jira/browse/IGNITE-21707 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > Time Spent: 20m > Remaining Estimate: 0h > > We use 5.x version of https://github.com/OpenAPITools/openapi-generator but > the latest one is 7.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21649) Fix warning caused by PMD configuration referencing nonexisting rule
[ https://issues.apache.org/jira/browse/IGNITE-21649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21649: - Labels: ignite-3 (was: ) > Fix warning caused by PMD configuration referencing nonexisting rule > > > Key: IGNITE-21649 > URL: https://issues.apache.org/jira/browse/IGNITE-21649 > Project: Ignite > Issue Type: Improvement >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21592) module packaging-java-client may produce artifact resolution error under some environments
[
https://issues.apache.org/jira/browse/IGNITE-21592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21592:
-
Labels: ignite-3 (was: )
> module packaging-java-client may produce artifact resolution error under some
> environments
> --
>
> Key: IGNITE-21592
> URL: https://issues.apache.org/jira/browse/IGNITE-21592
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Assignee: Viacheslav Blinov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After merging IGNITE-21432 and running the following build target:
> {noformat}
> ./gradlew build -x test -x integrationTest --continue{noformat}
> The build fails with following symptoms
> {noformat}
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':packaging-java-client:distZip'.
> > Could not resolve all files for configuration
> > ':packaging-java-client:javaClient'.
> > Could not resolve com.github.ben-manes.caffeine:caffeine:3.0.4.
> Required by:
> project :packaging-java-client > project :ignite-client > project
> :ignite-marshaller-common
> > The consumer was configured to find attribute
> 'org.gradle.jvm.environment' with value 'standard-jvm'. However we cannot
> choose between the following variants of
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - apiElements
> - javadocElements
> - runtimeElements
> - shadowRuntimeElements
> - sourcesElements
> All of them match the consumer attributes:
> - Variant 'apiElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.jvm.version '11' but the consumer
> didn't ask for it
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-api' but the consumer
> didn't ask for it
> - Variant 'javadocElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'documentation' but the
> consumer didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Provides org.gradle.docstype 'javadoc' but the consumer
> didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-runtime' but the consumer
> didn't ask for it
> - Variant 'runtimeElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.jvm.version '11' but the consumer
> didn't ask for it
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-runtime' but the consumer
> didn't ask for it
> - Variant 'shadowRuntimeElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'shadowed' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
> didn't
[jira] [Updated] (IGNITE-21700) IgniteSort: result of RelOptCost.plus is ignored but it doesn't have side-effects
[
https://issues.apache.org/jira/browse/IGNITE-21700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21700:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> IgniteSort: result of RelOptCost.plus is ignored but it doesn't have
> side-effects
> -
>
> Key: IGNITE-21700
> URL: https://issues.apache.org/jira/browse/IGNITE-21700
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
> Fix For: 3.0.0-beta2
>
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H D RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT RV: Return value of
> org.apache.calcite.plan.RelOptCost.plus(RelOptCost) ignored, but method has
> no side effect At IgniteSort.java:[line 169] {noformat}
> It looks like RelOptCost.plus is side-effect free and it's return result
> should be used, but it is ignored! It looks like a bug!
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21693) TxManagerImpl increments/decrements volatile field `inflights`
[
https://issues.apache.org/jira/browse/IGNITE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21693:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> TxManagerImpl increments/decrements volatile field `inflights`
> --
>
> Key: IGNITE-21693
> URL: https://issues.apache.org/jira/browse/IGNITE-21693
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H M VO_VOLATILE_INCREMENT VO: Increment of volatile field
> org.apache.ignite.internal.tx.impl.TxManagerImpl$TxContext.inflights in
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$addInflight$21(boolean[],
> UUID, TxManagerImpl$TxContext) At TxManagerImpl.java:[line 843]
> H M VO_VOLATILE_INCREMENT VO: Increment of volatile field
> org.apache.ignite.internal.tx.impl.TxManagerImpl$TxContext.inflights in
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$removeInflight$22(UUID,
> TxManagerImpl$TxContext) At TxManagerImpl.java:[line 858]
> {noformat}
> Increments/Decrements of volatile fields aren't atomic. If more than one
> thread is incrementing/decrementing the field at the same time,
> increments/decrements could be lost.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21710) ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes fails with Could not wait for the replica readiness due to timeout [replicaGroupId=7_part_0, req=Read
[ https://issues.apache.org/jira/browse/IGNITE-21710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21710: - Labels: ignite-3 (was: ) > ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes fails with > Could not wait for the replica readiness due to timeout > [replicaGroupId=7_part_0, req=ReadWriteSingleRowReplicaRequestImpl] > - > > Key: IGNITE-21710 > URL: https://issues.apache.org/jira/browse/IGNITE-21710 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21705) CheckpointWorkflow uses weird equals implementation
[
https://issues.apache.org/jira/browse/IGNITE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21705:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> CheckpointWorkflow uses weird equals implementation
> ---
>
> Key: IGNITE-21705
> URL: https://issues.apache.org/jira/browse/IGNITE-21705
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS BC: Equals method for
> org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow$1
> assumes the argument is of type CheckpointWorkflow$1 At
> CheckpointWorkflow.java:[line 349]
> M B NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT NP:
> org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow$1.equals(Object)
> does not check for null argument At CheckpointWorkflow.java:[line 349]
> {noformat}
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21703) Sql. IgniteSqlFunctions.octetLength relies on default encoding
[
https://issues.apache.org/jira/browse/IGNITE-21703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21703:
-
Labels: ignite-3 (was: ignite3)
> Sql. IgniteSqlFunctions.octetLength relies on default encoding
> --
>
> Key: IGNITE-21703
> URL: https://issues.apache.org/jira/browse/IGNITE-21703
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H I DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.octetLength(String):
> String.getBytes() At IgniteSqlFunctions.java:[line 133]
> {noformat}
> It looks like a potential bug if system default encoding will be something
> exotic.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21702) AbstractNode field `inBufSize` is unused
[
https://issues.apache.org/jira/browse/IGNITE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21702:
-
Labels: ignite-3 (was: ignite3)
> AbstractNode field `inBufSize` is unused
>
>
> Key: IGNITE-21702
> URL: https://issues.apache.org/jira/browse/IGNITE-21702
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P SS_SHOULD_BE_STATIC SS: Unread field:
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.inBufSize; should
> this field be static? At AbstractNode.java:[line 39] {noformat}
> It looks like this field is just useless.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21704) ConfigurationListenerHolder uses weird equals implementation
[
https://issues.apache.org/jira/browse/IGNITE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21704:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> ConfigurationListenerHolder uses weird equals implementation
>
>
> Key: IGNITE-21704
> URL: https://issues.apache.org/jira/browse/IGNITE-21704
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS BC: Equals method for
> org.apache.ignite.internal.configuration.ConfigurationListenerHolder$1
> assumes the argument is of type ConfigurationListenerHolder$1 At
> ConfigurationListenerHolder.java:[line 56]
> M B NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT NP:
> org.apache.ignite.internal.configuration.ConfigurationListenerHolder$1.equals(Object)
> does not check for null argument At ConfigurationListenerHolder.java:[line
> 56]{noformat}
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21706) RandomLruPageReplacementPolicy has dead conditions
[
https://issues.apache.org/jira/browse/IGNITE-21706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21706:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> RandomLruPageReplacementPolicy has dead conditions
> --
>
> Key: IGNITE-21706
> URL: https://issues.apache.org/jira/browse/IGNITE-21706
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H D UC_USELESS_CONDITION UC: Useless condition: it's known that dirty ==
> false at this point At RandomLruPageReplacementPolicy.java:[line 134]
> {noformat}
> I tried to unfold it and ended up removing quite a few lines of dead code and
> useless conditions which are constant. I'm not sure if this is right and
> there is no missing implementation there.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21701) Sql. IgniteSender compares unrelated types
[
https://issues.apache.org/jira/browse/IGNITE-21701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21701:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> Sql. IgniteSender compares unrelated types
> --
>
> Key: IGNITE-21701
> URL: https://issues.apache.org/jira/browse/IGNITE-21701
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M C EC_UNRELATED_TYPES_USING_POINTER_EQUALITY EC: Using pointer equality to
> compare a org.apache.calcite.rel.RelDistributions$RelDistributionImpl with a
> org.apache.ignite.internal.sql.engine.trait.IgniteDistribution in new
> org.apache.ignite.internal.sql.engine.rel.IgniteSender(RelOptCluster,
> RelTraitSet, RelNode, long, long, IgniteDistribution) At
> IgniteSender.java:[line 58]
> {noformat}
> It looks like a bug because this comparsion will always yield false!
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21698) LocalConfigurationStorage reboxes unboxed value
[
https://issues.apache.org/jira/browse/IGNITE-21698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21698:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> LocalConfigurationStorage reboxes unboxed value
> ---
>
> Key: IGNITE-21698
> URL: https://issues.apache.org/jira/browse/IGNITE-21698
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P BX_UNBOXING_IMMEDIATELY_REBOXED Bx: Boxed value is unboxed and then
> immediately reboxed in
> org.apache.ignite.internal.configuration.storage.LocalConfigurationStorage.lambda$lastRevision$6()
> At LocalConfigurationStorage.java:[line 232] {noformat}
> This might cause unwanted additional GC pressure.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21699) Sql. DistributionFunction compares strings by reference
[
https://issues.apache.org/jira/browse/IGNITE-21699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21699:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> Sql. DistributionFunction compares strings by reference
> ---
>
> Key: IGNITE-21699
> URL: https://issues.apache.org/jira/browse/IGNITE-21699
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B ES_COMPARING_STRINGS_WITH_EQ ES: Comparison of String objects using == or
> != in
> org.apache.ignite.internal.sql.engine.trait.DistributionFunction.equals(Object)
> At DistributionFunction.java:[line 76]
> M B ES_COMPARING_STRINGS_WITH_EQ ES: Comparison of String objects using == or
> != in
> org.apache.ignite.internal.sql.engine.trait.DistributionFunction.satisfy(DistributionFunction,
> DistributionFunction) At DistributionFunction.java:[line 117]
> {noformat}
> This might be wrong.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21696) LazyStripedExecutor performs synchronization on AtomicReferenceArray
[
https://issues.apache.org/jira/browse/IGNITE-21696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21696:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> LazyStripedExecutor performs synchronization on AtomicReferenceArray
>
>
> Key: IGNITE-21696
> URL: https://issues.apache.org/jira/browse/IGNITE-21696
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Assignee: Roman Puchkovskiy
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M M JLM_JSR166_UTILCONCURRENT_MONITORENTER JLM: Synchronization performed on
> java.util.concurrent.atomic.AtomicReferenceArray in
> org.apache.ignite.internal.network.LazyStripedExecutors.stripedExecutorFor(short)
> At LazyStripedExecutors.java:[line 71]
> {noformat}
> Instances of java.util.concurrent.atomic classes have their own concurrency
> control mechanisms that are orthogonal to the synchronization provided by the
> Java keyword {{{}synchronized{}}}. For example, synchronizing on an
> {{AtomicBoolean}} will not prevent other threads from modifying the
> {{{}AtomicBoolean{}}}.
> Such code may be correct, but should be carefully reviewed and documented,
> and may confuse people who have to maintain the code at a later date.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21697) ConnectionManager ignores exceptional return value of ExecutorService.submit
[
https://issues.apache.org/jira/browse/IGNITE-21697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21697:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> ConnectionManager ignores exceptional return value of ExecutorService.submit
>
>
> Key: IGNITE-21697
> URL: https://issues.apache.org/jira/browse/IGNITE-21697
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B RV_RETURN_VALUE_IGNORED_BAD_PRACTICE RV: Exceptional return value of
> java.util.concurrent.ExecutorService.submit(Callable) ignored in
> org.apache.ignite.internal.network.netty.ConnectionManager.handleNodeLeft(String)
> At ConnectionManager.java:[line 603]
> {noformat}
> If you don't check the result, you won't notice if the method invocation
> signals unexpected behavior by returning an atypical return value.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21695) PageHandler: useless control flow
[
https://issues.apache.org/jira/browse/IGNITE-21695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21695:
-
Labels: ignite-3 spotbus (was: ignite3 spotbus)
> PageHandler: useless control flow
> -
>
> Key: IGNITE-21695
> URL: https://issues.apache.org/jira/browse/IGNITE-21695
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbus
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M D UCF_USELESS_CONTROL_FLOW UCF: Useless control flow in
> org.apache.ignite.internal.pagememory.util.PageHandler. for PageHandler>() At PageHandler.java:[line 34]
> {noformat}
> One of the conditions of this interface default implementation checks for
> condition which is always true/false. This can be a sign of a bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21694) HeapLockManager/HeapUnboundedLockManager makes inefficient use of keySet iterator instead of entrySet iterator
[
https://issues.apache.org/jira/browse/IGNITE-21694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21694:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> HeapLockManager/HeapUnboundedLockManager makes inefficient use of keySet
> iterator instead of entrySet iterator
> --
>
> Key: IGNITE-21694
> URL: https://issues.apache.org/jira/browse/IGNITE-21694
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P WMI_WRONG_MAP_ITERATOR WMI:
> org.apache.ignite.internal.tx.impl.HeapLockManager$WaiterImpl.recalculate()
> makes inefficient use of keySet iterator instead of entrySet iterator At
> HeapLockManager.java:[line 815]
> M P WMI_WRONG_MAP_ITERATOR WMI:
> org.apache.ignite.internal.tx.impl.HeapUnboundedLockManager$WaiterImpl.recalculate()
> makes inefficient use of keySet iterator instead of entrySet iterator At
> HeapUnboundedLockManager.java:[line 632] {noformat}
> This method accesses the value of a Map entry, using a key that was retrieved
> from a keySet iterator. It is more efficient to use an iterator on the
> entrySet of the map, to avoid the Map.get(key) lookup.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21692) AbstractFreeList has unused private method `initReusedPage`
[
https://issues.apache.org/jira/browse/IGNITE-21692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21692:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> AbstractFreeList has unused private method `initReusedPage`
> ---
>
> Key: IGNITE-21692
> URL: https://issues.apache.org/jira/browse/IGNITE-21692
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M P UPM_UNCALLED_PRIVATE_METHOD UPM: Private method
> org.apache.ignite.internal.pagememory.freelist.AbstractFreeList.initReusedPage(Storable,
> long, IoStatisticsHolder) is never called At AbstractFreeList.java:[lines
> 707-726]
> {noformat}
> Method `initReusedPage` is never called which can be an indicator of an issue.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21691) BasicMetricExporter has inconsistent synchronized access to field `configuration`
[
https://issues.apache.org/jira/browse/IGNITE-21691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21691:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> BasicMetricExporter has inconsistent synchronized access to field
> `configuration`
> -
>
> Key: IGNITE-21691
> URL: https://issues.apache.org/jira/browse/IGNITE-21691
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.metrics.exporters.BasicMetricExporter.configuration;
> locked 66% of time Unsynchronized access at BasicMetricExporter.java:[line
> 41]
> {noformat}
> Field `configuration` are accessed in both synchronized and unsynchronized
> fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21690) ConfigurationNode has inconsistent synchronized access to fields `invalid` and `val`
[
https://issues.apache.org/jira/browse/IGNITE-21690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21690:
-
Labels: ignite-3 ignite3 spotbugs (was: ignite3 spotbugs)
> ConfigurationNode has inconsistent synchronized access to fields `invalid`
> and `val`
>
>
> Key: IGNITE-21690
> URL: https://issues.apache.org/jira/browse/IGNITE-21690
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, ignite3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.invalid; locked
> 66% of time Unsynchronized access at ConfigurationNode.java:[line
> 138]{noformat}
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.val; locked 60% of
> time Unsynchronized access at ConfigurationNode.java:[line 145]{noformat}
> Fields `val` and `invalid` are accessed in both synchronized and
> unsynchronized fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21690) ConfigurationNode has inconsistent synchronized access to fields `invalid` and `val`
[
https://issues.apache.org/jira/browse/IGNITE-21690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21690:
-
Labels: ignite-3 spotbugs (was: ignite-3 ignite3 spotbugs)
> ConfigurationNode has inconsistent synchronized access to fields `invalid`
> and `val`
>
>
> Key: IGNITE-21690
> URL: https://issues.apache.org/jira/browse/IGNITE-21690
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.invalid; locked
> 66% of time Unsynchronized access at ConfigurationNode.java:[line
> 138]{noformat}
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.val; locked 60% of
> time Unsynchronized access at ConfigurationNode.java:[line 145]{noformat}
> Fields `val` and `invalid` are accessed in both synchronized and
> unsynchronized fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21689) Correct CI jobs to remove modernizer calls
[ https://issues.apache.org/jira/browse/IGNITE-21689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21689: - Labels: ignite-3 (was: ignite3) > Correct CI jobs to remove modernizer calls > -- > > Key: IGNITE-21689 > URL: https://issues.apache.org/jira/browse/IGNITE-21689 > Project: Ignite > Issue Type: Task >Reporter: Viacheslav Blinov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Before merging IGNITE-21688 we should remove modernizer usage from our CI > pipelines -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21688) Remove Modernizer from gradle build
[ https://issues.apache.org/jira/browse/IGNITE-21688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21688: - Labels: ignite-3 (was: ignite3) > Remove Modernizer from gradle build > --- > > Key: IGNITE-21688 > URL: https://issues.apache.org/jira/browse/IGNITE-21688 > Project: Ignite > Issue Type: Task >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > > After IGNITE-21569 is implemented all existing modernizer rules will be > covered by Spotbugs. Let's get rid of modernizer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21666) Define base events
[ https://issues.apache.org/jira/browse/IGNITE-21666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21666: - Labels: ignite-3 (was: ) > Define base events > -- > > Key: IGNITE-21666 > URL: https://issues.apache.org/jira/browse/IGNITE-21666 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > The base events should be defined with fields: > - EventType > - User > - Time > - Type-specific fields > Also two event types are defined in this ticket: CONNECTION_ESTABLISHED, > CONNECTION_CLOSED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21650) Extend PMD ruleset to check known performance and multithreading issues
[ https://issues.apache.org/jira/browse/IGNITE-21650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21650: - Labels: ignite-3 (was: ) > Extend PMD ruleset to check known performance and multithreading issues > --- > > Key: IGNITE-21650 > URL: https://issues.apache.org/jira/browse/IGNITE-21650 > Project: Ignite > Issue Type: Improvement >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > > See > [https://pmd.sourceforge.io/pmd-6.50.0/pmd_rules_java_performance.html] > and > https://pmd.sourceforge.io/pmd-6.50.0/pmd_rules_java_multithreading.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21665) Implement EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21665: - Labels: ignite-3 (was: ) > Implement EventLog > -- > > Key: IGNITE-21665 > URL: https://issues.apache.org/jira/browse/IGNITE-21665 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Given FileSink and CONNECTION_ESTABLISHED/CONNECTION_CLOSED events > implemented we have to be able to configure a channel for it with > CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the > configuration the EventLog itself should be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21657) Sql. SqlTestUtils::assertThrowsSqlException reports misleading error message
[ https://issues.apache.org/jira/browse/IGNITE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21657: - Labels: ignite-3 (was: ) > Sql. SqlTestUtils::assertThrowsSqlException reports misleading error message > > > Key: IGNITE-21657 > URL: https://issues.apache.org/jira/browse/IGNITE-21657 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Trivial > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The condition in error reporting is misleading, it should display a error > message when a message does not match, but it displays error codes (which > match). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21644: - Labels: ignite-3 (was: ) > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21622) Add .editorconfig to the repo
[ https://issues.apache.org/jira/browse/IGNITE-21622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21622: - Labels: ignite-3 (was: ) > Add .editorconfig to the repo > - > > Key: IGNITE-21622 > URL: https://issues.apache.org/jira/browse/IGNITE-21622 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Sometimes I see missing EOF in the PR. I would like to add an .editorconfig > to the repo in order to avoid mentioning in everytime in PR. > https://editorconfig.org > - collect useful options in .editorconfig that will speedup a review process > - present them to the community > - integrate the config into repository > - write documentation if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18258) .NET: LINQ: Clean up inlineConstArgs logic
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18258:
Description:
Previously, there was a bug in SQL engine:
*Query*
{code}
select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
PUBLIC.TBL_INT32 as _T0
{code}
*Result*
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
ConverterUtils#convertToDecimal method should be used instead.
at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
at
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
at
java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
at
java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
at
java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.AssertionError: For conversion to decimal,
ConverterUtils#convertToDecimal method should be used instead.
at
org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
at
org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
at
org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1106)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1093)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
at
org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.ap
[jira] [Updated] (IGNITE-18258) .NET: LINQ: Clean up inlineConstArgs logic
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18258:
Component/s: thin client
(was: sql)
> .NET: LINQ: Clean up inlineConstArgs logic
> --
>
> Key: IGNITE-18258
> URL: https://issues.apache.org/jira/browse/IGNITE-18258
> 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
>
>
> *Query*
> {code}
> select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
> PUBLIC.TBL_INT32 as _T0
> {code}
> *Result*
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
> at
> org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1106)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.v
[jira] [Updated] (IGNITE-18258) .NET: LINQ: Clean up inlineConstArgs logic
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18258:
Labels: .NET LINQ ignite-3 (was: ignite-3)
> .NET: LINQ: Clean up inlineConstArgs logic
> --
>
> Key: IGNITE-18258
> URL: https://issues.apache.org/jira/browse/IGNITE-18258
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, LINQ, ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
> PUBLIC.TBL_INT32 as _T0
> {code}
> *Result*
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
> at
> org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1106)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.vi
[jira] [Updated] (IGNITE-18258) .NET: LINQ: Clean up inlineConstArgs logic
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18258:
Summary: .NET: LINQ: Clean up inlineConstArgs logic (was: Exception on
cast to decimal and numeric in SQL)
> .NET: LINQ: Clean up inlineConstArgs logic
> --
>
> Key: IGNITE-18258
> URL: https://issues.apache.org/jira/browse/IGNITE-18258
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
> PUBLIC.TBL_INT32 as _T0
> {code}
> *Result*
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
> at
> org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1106)
> at
> org.apache.ignite.inter
[jira] [Commented] (IGNITE-18258) Exception on cast to decimal and numeric in SQL
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825647#comment-17825647
]
Pavel Tupitsyn commented on IGNITE-18258:
-
As discussed with [~mzhuravkov], the problem no longer exists on the SQL engine
side. Reassigned to myself to tweak .NET code accordingly and remove TODOs.
> Exception on cast to decimal and numeric in SQL
> ---
>
> Key: IGNITE-18258
> URL: https://issues.apache.org/jira/browse/IGNITE-18258
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
> PUBLIC.TBL_INT32 as _T0
> {code}
> *Result*
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
> at
> org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec
[jira] [Assigned] (IGNITE-18258) Exception on cast to decimal and numeric in SQL
[
https://issues.apache.org/jira/browse/IGNITE-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-18258:
---
Assignee: Pavel Tupitsyn (was: Maksim Zhuravkov)
> Exception on cast to decimal and numeric in SQL
> ---
>
> Key: IGNITE-18258
> URL: https://issues.apache.org/jira/browse/IGNITE-18258
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select (cast(_T0.KEY as decimal) / ?), cast(_T0.KEY as numeric) from
> PUBLIC.TBL_INT32 as _T0
> {code}
> *Result*
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:9b69e26a-0d1e-4891-82bb-f164919a323c For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$acknowledgeFragment$1(ExecutionServiceImpl.java:453)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.acknowledgeFragment(ExecutionServiceImpl.java:452)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:310)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$3(ExecutionServiceImpl.java:183)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:135)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:222)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ConverterUtils.convert(ConverterUtils.java:201)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:1249)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitDynamicParam(RexToLixTranslator.java:80)
> at
> org.apache.calcite.rex.RexDynamicParam.accept(RexDynamicParam.java:60)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:983)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1106)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator
[jira] [Assigned] (IGNITE-21580) Sql. Unable to optimise query using only two phase aggregates
[
https://issues.apache.org/jira/browse/IGNITE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21580:
-
Assignee: Maksim Zhuravkov
> Sql. Unable to optimise query using only two phase aggregates
> -
>
> Key: IGNITE-21580
> URL: https://issues.apache.org/jira/browse/IGNITE-21580
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> As for now, query planner returns following plan for q1 from TPC H suite:
> {code:java}
> IgniteColocatedSortAggregate
> IgniteExchange(distribution=[single])
> IgniteSort
> IgniteIndexScan(index=[L_SD], searchBounds=[[RangeBounds
> [lowerBound=null, upperBound=-(1998-12-01, 777600:INTERVAL DAY),
> lowerInclude=true, upperInclude=true]]])
> {code}
> The first problem is it's not even optimal variant from possible ones. By
> simply excluding {{SortAggregateConverterRule.COLOCATED}} from planning
> phase, we will get plan as follow:
> {code:java}
> IgniteSort
> IgniteColocatedHashAggregate
> IgniteExchange(distribution=[single])
> IgniteIndexScan(index=[L_SD], searchBounds=[[RangeBounds
> [lowerBound=null, upperBound=-(1998-12-01, 777600:INTERVAL DAY),
> lowerInclude=true, upperInclude=true]]])
> {code}
> Latter plan is executed ~40% faster than the first one.
> Seems, it's possible to reduce time even further by taking an advantage of
> two-phase aggregates, but disabling both version of colocated aggregates
> results in an exception during planning phase.
> Within this ticket, let's address the issue preventing optimiser from usage
> of two-phase aggregates, and also tweak cost function to make optimiser
> choose better plan.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations with impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's remove this redundant operations by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This query performs an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 to eliminate all
results
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's remove this redundant operations by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This query performs an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
> Sql. Do not perform index operations with impossible search conditions for
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 to eliminate
> all results
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations impossible search conditions with numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Summary: Sql. Do not perform index operations impossible search conditions
with numeric literals. (was: Sql. Do not perform index operations impossible
search conditions with numeric literals.)
> Sql. Do not perform index operations impossible search conditions with
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations impossible search conditions with numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Summary: Sql. Do not perform index operations impossible search conditions
with numeric literals. (was: Sql. Do not perform index operations for
impossible search conditions with numeric literals.)
> Sql. Do not perform index operations impossible search conditions with
> numeric literals.
> -
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations with impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Summary: Sql. Do not perform index operations with impossible search
conditions for numeric literals. (was: Sql. Do not perform index operations
impossible search conditions with numeric literals.)
> Sql. Do not perform index operations with impossible search conditions for
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations for impossible search conditions with numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's remove this redundant operations by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This query performs an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This query performs an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
> Sql. Do not perform index operations for impossible search conditions with
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's remove this redundant operations by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index operations for impossible search conditions with numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Summary: Sql. Do not perform index operations for impossible search
conditions with numeric literals. (was: Sql. Do not perform index lookups for
impossible search conditions for numeric literals.)
> Sql. Do not perform index operations for impossible search conditions with
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index lookups for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Summary: Sql. Do not perform index lookups for impossible search conditions
for numeric literals. (was: Sql. Do not perform index scan operations for
impossible search conditions for numeric literals.)
> Sql. Do not perform index lookups for impossible search conditions for
> numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This operation perform an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This operation perform an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This query performs an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// Behaviour:
// This operation perform an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // Behaviour:
> // This query performs an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types (see examples).
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update Index*ScanNode, to always produce no row, in cause when they use such
bounds.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform as an index look up to returns all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Fix Version/s: 3.0.0-beta2
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform an index look up to return all rows that have
tinyint_col = SHORT::MAX_VALUE
// Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate all
results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types.
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update IndexScanNode to always produce no rows in cause when impossible
bounds are being used.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types.
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update IndexScanNode to always produce no rows in cause when impossible
> bounds are being used.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform an index look up to return all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // Then it applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Description:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types (see examples).
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows (See example).
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update Index*ScanNode, to always produce no row, in cause when they use such
bounds.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
was:
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types (see examples).
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows.
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update Index*ScanNode, to always produce no row, in cause when they use such
bounds.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types (see examples).
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows (See example).
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update Index*ScanNode, to always produce no row, in cause when they use
> such bounds.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform as an index look up to returns all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
Maksim Zhuravkov created IGNITE-21736:
-
Summary: Sql. Do not perform index scan operations for impossible
search conditions for numeric literals.
Key: IGNITE-21736
URL: https://issues.apache.org/jira/browse/IGNITE-21736
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Maksim Zhuravkov
IGNITE-19615 introduced saturated values to overcome a problem in index
lookups, caused by the fact that SQL allows implict conversions between numeric
types (see examples).
This approach is not effiecent because instead of immediately returning an
empty collection of rows, IndexScanNode performs a look up for TYPE::MAX_VALUE
and then applying post condition to remove rows.
1. Let's fix remove this redudant lookup by introducing/updating search bounds
that represent unsatisfiable/impossible conditions (conditions that never hold
true).
2. Let's fix code related to introduction of saturated values to use these
bounds.
3. Update Index*ScanNode, to always produce no row, in cause when they use such
bounds.
Example:
{code:java}
SELECT * FROM t WHERE t.tinyint_col = 11
{code}
With type annotations:
{code:java}
SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
{code}
After applying type coercions rules:
{code:java}
SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
// This operation perform as an index look up to returns all rows that have
tinyint_col = SHORT::MAX_VALUE
// and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
all results)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21736) Sql. Do not perform index scan operations for impossible search conditions for numeric literals.
[
https://issues.apache.org/jira/browse/IGNITE-21736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21736:
--
Labels: ignite-3 (was: )
> Sql. Do not perform index scan operations for impossible search conditions
> for numeric literals.
>
>
> Key: IGNITE-21736
> URL: https://issues.apache.org/jira/browse/IGNITE-21736
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> IGNITE-19615 introduced saturated values to overcome a problem in index
> lookups, caused by the fact that SQL allows implict conversions between
> numeric types (see examples).
> This approach is not effiecent because instead of immediately returning an
> empty collection of rows, IndexScanNode performs a look up for
> TYPE::MAX_VALUE and then applying post condition to remove rows.
> 1. Let's fix remove this redudant lookup by introducing/updating search
> bounds that represent unsatisfiable/impossible conditions (conditions that
> never hold true).
> 2. Let's fix code related to introduction of saturated values to use these
> bounds.
> 3. Update Index*ScanNode, to always produce no row, in cause when they use
> such bounds.
> Example:
> {code:java}
> SELECT * FROM t WHERE t.tinyint_col = 11
> {code}
> With type annotations:
> {code:java}
> SELECT * FROM t WHERE t.t.tinyint_col (TINYINT) = 11 (INT)
> {code}
> After applying type coercions rules:
> {code:java}
> SELECT * FROM t WHERE CAST(t.tiny_int AS INT) = 11
> // This operation perform as an index look up to returns all rows that have
> tinyint_col = SHORT::MAX_VALUE
> // and then applies a predicate CAST(tinyint_col) = 11 (to eliminate
> all results)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21362) Just inserted row not found when using KV api
[
https://issues.apache.org/jira/browse/IGNITE-21362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21362:
--
Fix Version/s: 3.0.0-beta2
> Just inserted row not found when using KV api
> -
>
> Key: IGNITE-21362
> URL: https://issues.apache.org/jira/browse/IGNITE-21362
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Consider the following scenario:
> {code:java}
> sql("CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY (c2,
> c1))"); // mind the order of columns in PK definition
> Tuple key = Tuple.create()
> .set("c1", 1)
> .set("c2", 2);
> Tuple val = Tuple.create()
> .set("c3", 3);
> KeyValueView kv = igniteNode
> .tables()
> .table("my")
> .keyValueView();
> kv.put(null, key, val);
> Tuple result = kv.get(null, key); // <-- returns null here
> {code}
> Expected behaviour is to get result equals to {{val}} that we've just put to
> the table, but {{kv.get()}} returns {{null}} in this case. If we change the
> order of columns in PK definition to (c1, c2), then the test will pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21362) Just inserted row not found when using KV api
[
https://issues.apache.org/jira/browse/IGNITE-21362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov resolved IGNITE-21362.
---
Resolution: Fixed
Was fixed by IGNITE-19744
> Just inserted row not found when using KV api
> -
>
> Key: IGNITE-21362
> URL: https://issues.apache.org/jira/browse/IGNITE-21362
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
>
> Consider the following scenario:
> {code:java}
> sql("CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY (c2,
> c1))"); // mind the order of columns in PK definition
> Tuple key = Tuple.create()
> .set("c1", 1)
> .set("c2", 2);
> Tuple val = Tuple.create()
> .set("c3", 3);
> KeyValueView kv = igniteNode
> .tables()
> .table("my")
> .keyValueView();
> kv.put(null, key, val);
> Tuple result = kv.get(null, key); // <-- returns null here
> {code}
> Expected behaviour is to get result equals to {{val}} that we've just put to
> the table, but {{kv.get()}} returns {{null}} in this case. If we change the
> order of columns in PK definition to (c1, c2), then the test will pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21735) Upgrade table rendering library
Aleksandr created IGNITE-21735: -- Summary: Upgrade table rendering library Key: IGNITE-21735 URL: https://issues.apache.org/jira/browse/IGNITE-21735 Project: Ignite Issue Type: Improvement Components: cli Reporter: Aleksandr We use outdated library for tables rendering in cli (FlipTables). The new version of this library is https://github.com/JakeWharton/picnic The reason why I've started looking at a new library was that we are not able to render ANSI colors inside table's cells. ANSI tags break the calculation logic of borders. We should try to use a new library to render tables with ANSI. I am afraid the same problem for this lib but at least we've tried. In case the problem is not solved, I propose forking of the original library and fixing the problem with ANSI colors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21696) LazyStripedExecutor performs synchronization on AtomicReferenceArray
[
https://issues.apache.org/jira/browse/IGNITE-21696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21696:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> LazyStripedExecutor performs synchronization on AtomicReferenceArray
>
>
> Key: IGNITE-21696
> URL: https://issues.apache.org/jira/browse/IGNITE-21696
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Assignee: Roman Puchkovskiy
>Priority: Minor
> Labels: ignite3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M M JLM_JSR166_UTILCONCURRENT_MONITORENTER JLM: Synchronization performed on
> java.util.concurrent.atomic.AtomicReferenceArray in
> org.apache.ignite.internal.network.LazyStripedExecutors.stripedExecutorFor(short)
> At LazyStripedExecutors.java:[line 71]
> {noformat}
> Instances of java.util.concurrent.atomic classes have their own concurrency
> control mechanisms that are orthogonal to the synchronization provided by the
> Java keyword {{{}synchronized{}}}. For example, synchronizing on an
> {{AtomicBoolean}} will not prevent other threads from modifying the
> {{{}AtomicBoolean{}}}.
> Such code may be correct, but should be carefully reviewed and documented,
> and may confuse people who have to maintain the code at a later date.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21523) ItNodeRestartsTest.testRestarts is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825539#comment-17825539
]
Roman Puchkovskiy edited comment on IGNITE-21523 at 3/12/24 7:15 AM:
-
The problem was caused by the following: there seems to be something like a
race between a server socket closure and an acceptance of an incoming
connection. If a client was opening a connection to the server right when the
server was shutdown, the connection seemed to be opened for the client, but the
server never realized that it accepted that connection (and so it did not close
it during its stop procedure). As a result, the connection was alive from the
point of view of the client, but it was abandoned on the server.
I solved this by adding a send of a 'probe' message from the client to the
server right after the connection gets opened at the client. This allows to
detect such a broken channel and reopen it later. It is a form of a one-time
heartbeat. Later, we should introduce a proper heartbeat mechanism (and remove
that 'probe' sending), see IGNITE-21734.
was (Author: rpuch):
The problem was caused by the following: there seems to be something like a
race between a server socket closure and an acceptance of an incoming
connection. If a client was opening a connection to the server right when the
server was shutdown, the connection seemed to be opened for the client, but the
server never realized that it accepted that connection (and so it did not close
it during its stop procedure). As a result, the connection was alive from the
point of view of the client, but it was abandoned on the server.
I solved this by adding a send of a 'probe' message from the client to the
server right after the connection gets opened at the client. This allows to
detect such a broken channel and reopen it later. It is a form of a one-time
heartbeat. Later, we should introduce a proper heartbeat mechanism (and remove
that 'probe' sending).
> ItNodeRestartsTest.testRestarts is flaky
>
>
> Key: IGNITE-21523
> URL: https://issues.apache.org/jira/browse/IGNITE-21523
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After running the test repeatedly, the following happened: after a restart of
> 2 clusterServices, one of the restarted cluster services (port 3344) and one
> of not restarted cluster services (port 3345) could not 'see' each other due
> to metadata obtaining timeout:
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MetadataStore]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][56ad9288-7ce4-4f67-b11c-8e1eaf6d6612]
> Timeout getting GetMetadataResp from 127.0.1.1:3344 within 1000 ms, cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MembershipProtocol]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][updateMembership][SYNC]
> Skipping to add/update member: \{m:
> default:inrt_tr_3344:788fea0a8f9b4251@127.0.1.1:3344, s: ALIVE, inc: 0}, due
> to failed fetchMetadata call (cause: java.util.concurrent.TimeoutException:
> Did not observe any item or terminal signal within 1000ms in
> 'source(MonoDefer)' (and no fallback has been configured))
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21734) Send heatbeats via a network channel
[ https://issues.apache.org/jira/browse/IGNITE-21734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21734: --- Description: A TCP connection might 'break'; such a broken state can only be detected by attempting to send something through the connection. Periodically-sent heartbeats need to be added; each participant should send empty messages to its peer. The period between sends should be configurable; 500ms seems to be a good default. > Send heatbeats via a network channel > > > Key: IGNITE-21734 > URL: https://issues.apache.org/jira/browse/IGNITE-21734 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, network > > A TCP connection might 'break'; such a broken state can only be detected by > attempting to send something through the connection. Periodically-sent > heartbeats need to be added; each participant should send empty messages to > its peer. The period between sends should be configurable; 500ms seems to be > a good default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21734) Send heatbeats via a network channel
Roman Puchkovskiy created IGNITE-21734: -- Summary: Send heatbeats via a network channel Key: IGNITE-21734 URL: https://issues.apache.org/jira/browse/IGNITE-21734 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21523) ItNodeRestartsTest.testRestarts is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825539#comment-17825539
]
Roman Puchkovskiy commented on IGNITE-21523:
The problem was caused by the following: there seems to be something like a
race between a server socket closure and an acceptance of an incoming
connection. If a client was opening a connection to the server right when the
server was shutdown, the connection seemed to be opened for the client, but the
server never realized that it accepted that connection (and so it did not close
it during its stop procedure). As a result, the connection was alive from the
point of view of the client, but it was abandoned on the server.
I solved this by adding a send of a 'probe' message from the client to the
server right after the connection gets opened at the client. This allows to
detect such a broken channel and reopen it later. It is a form of a one-time
heartbeat. Later, we should introduce a proper heartbeat mechanism (and remove
that 'probe' sending).
> ItNodeRestartsTest.testRestarts is flaky
>
>
> Key: IGNITE-21523
> URL: https://issues.apache.org/jira/browse/IGNITE-21523
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After running the test repeatedly, the following happened: after a restart of
> 2 clusterServices, one of the restarted cluster services (port 3344) and one
> of not restarted cluster services (port 3345) could not 'see' each other due
> to metadata obtaining timeout:
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MetadataStore]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][56ad9288-7ce4-4f67-b11c-8e1eaf6d6612]
> Timeout getting GetMetadataResp from 127.0.1.1:3344 within 1000 ms, cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)
> [2024-02-12T14:16:54,968][WARN ][sc-cluster-3345-1409][MembershipProtocol]
> [default:inrt_tr_3345:13b7bdae21a14c86@127.0.1.1:3345][updateMembership][SYNC]
> Skipping to add/update member: \{m:
> default:inrt_tr_3344:788fea0a8f9b4251@127.0.1.1:3344, s: ALIVE, inc: 0}, due
> to failed fetchMetadata call (cause: java.util.concurrent.TimeoutException:
> Did not observe any item or terminal signal within 1000ms in
> 'source(MonoDefer)' (and no fallback has been configured))
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17767) Ignite 3.0: Additional indexes optimizations
[ https://issues.apache.org/jira/browse/IGNITE-17767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-17767. Resolution: Duplicate > Ignite 3.0: Additional indexes optimizations > > > Key: IGNITE-17767 > URL: https://issues.apache.org/jira/browse/IGNITE-17767 > Project: Ignite > Issue Type: Epic > Components: persistence >Reporter: Sergey Chugunov >Priority: Major > Labels: ignite-3 > > Some important optimizations that first version (IGNITE-17304 epic) lacks > have to be implemented: > # Inlining values into index rows. > # In-place replacement of values on updates. > # Optimized Comparators for specific storages (e.g. native comparator for > RocksDB storage). -- This message was sent by Atlassian Jira (v8.20.10#820010)
