[jira] [Updated] (IGNITE-21167) Sql. Change exception message raised while calling transactions with disabled autoCommit from jdbc

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-21167:
--
Fix Version/s: 3.0.0-beta2

> Sql. Change exception message raised while calling transactions with disabled 
> autoCommit from jdbc
> --
>
> Key: IGNITE-21167
> URL: https://issues.apache.org/jira/browse/IGNITE-21167
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> After ignite-20661 was implemented, statements like:
> {code:java}
> "START TRANSACTION; SELECT 1; COMMIT;"
> {code}
> will throw non friendly exception like :
> "Transaction control statement cannot be executed within an external 
> transaction"
> Need to be changed.
> Discussed in [1]
> [1] https://github.com/apache/ignite-3/pull/2906#discussion_r1420178983



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22197:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Move DDL 'IF EXISTS` flag handling inside the catalog command
> -
>
> Key: IGNITE-22197
> URL: https://issues.apache.org/jira/browse/IGNITE-22197
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT 
> EXISTS' flags. We handle the exception thrown by the command and set the 
> result to false if the flag was set. And this result (true/false) can be 
> obtained by the user using {{AsyncResultSet#wasApplied}} method.
> With the current approach, a problem may arise when processing a batch 
> command.
> For example
> {code:sql}
> CREATE TABLE IF NOT EXISTS Person...   -- command 1
> CREATE TABLE IF NOT EXISTS City... -- command 2
> {code}
> If the Person table exists, the batch will not be fully executed.
> To address this we can move flag handling inside the command itself.
> To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} 
> so that it returns not only the catalog version, but also a flag indicating 
> that something was changed when this command was executed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command

2024-05-08 Thread Pavel Pereslegin (Jira)
Pavel Pereslegin created IGNITE-22197:
-

 Summary: Move DDL 'IF EXISTS` flag handling inside the catalog 
command
 Key: IGNITE-22197
 URL: https://issues.apache.org/jira/browse/IGNITE-22197
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Pavel Pereslegin


Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT 
EXISTS' flags. We handle the exception thrown by the command and set the result 
to false if the flag was set. And this result (true/false) can be obtained by 
the user using {{AsyncResultSet#wasApplied}} method.

With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person...   -- command 1
CREATE TABLE IF NOT EXISTS City...-- command 2
{code}
If the Person table exists, the batch will not be fully executed.

To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so 
that it returns not only the catalog version, but also a flag indicating that 
something was changed when this command was executed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22197:
--
Description: 
Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT 
EXISTS' flags. We handle the exception thrown by the command and set the result 
to false if the flag was set. And this result (true/false) can be obtained by 
the user using {{AsyncResultSet#wasApplied}} method.

With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person...   -- command 1
CREATE TABLE IF NOT EXISTS City... -- command 2
{code}
If the Person table exists, the batch will not be fully executed.

To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so 
that it returns not only the catalog version, but also a flag indicating that 
something was changed when this command was executed.

  was:
Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT 
EXISTS' flags. We handle the exception thrown by the command and set the result 
to false if the flag was set. And this result (true/false) can be obtained by 
the user using {{AsyncResultSet#wasApplied}} method.

With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person...   -- command 1
CREATE TABLE IF NOT EXISTS City...-- command 2
{code}
If the Person table exists, the batch will not be fully executed.

To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so 
that it returns not only the catalog version, but also a flag indicating that 
something was changed when this command was executed.


> Move DDL 'IF EXISTS` flag handling inside the catalog command
> -
>
> Key: IGNITE-22197
> URL: https://issues.apache.org/jira/browse/IGNITE-22197
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT 
> EXISTS' flags. We handle the exception thrown by the command and set the 
> result to false if the flag was set. And this result (true/false) can be 
> obtained by the user using {{AsyncResultSet#wasApplied}} method.
> With the current approach, a problem may arise when processing a batch 
> command.
> For example
> {code:sql}
> CREATE TABLE IF NOT EXISTS Person...   -- command 1
> CREATE TABLE IF NOT EXISTS City... -- command 2
> {code}
> If the Person table exists, the batch will not be fully executed.
> To address this we can move flag handling inside the command itself.
> To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} 
> so that it returns not only the catalog version, but also a flag indicating 
> that something was changed when this command was executed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Pavel Tupitsyn (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn resolved IGNITE-22194.
-
Resolution: Fixed

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844692#comment-17844692
 ] 

Pavel Tupitsyn commented on IGNITE-22194:
-

Merged to main: 86bbb4322770b367ca380542b42ed0ea0a7db2f9

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (IGNITE-22176) Propagate Env from parent RocksDb in RocksSnapshotManager

2024-05-08 Thread Roman Puchkovskiy (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-22176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844687#comment-17844687
 ] 

Roman Puchkovskiy commented on IGNITE-22176:


The patch looks good to me

> Propagate Env from parent RocksDb in RocksSnapshotManager
> -
>
> Key: IGNITE-22176
> URL: https://issues.apache.org/jira/browse/IGNITE-22176
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Tiago Marques Godinho
>Priority: Minor
>  Labels: ignite-3
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The RocsDb environment should be the same as the parent db in the 
> RocksSnapshotManager#createSstFile method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22176) Propagate Env from parent RocksDb in RocksSnapshotManager

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy reassigned IGNITE-22176:
--

Assignee: Tiago Marques Godinho

> Propagate Env from parent RocksDb in RocksSnapshotManager
> -
>
> Key: IGNITE-22176
> URL: https://issues.apache.org/jira/browse/IGNITE-22176
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Tiago Marques Godinho
>Priority: Minor
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The RocsDb environment should be the same as the parent db in the 
> RocksSnapshotManager#createSstFile method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22196) Sort out JMX exporter MBeans root issues

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-22196:
---
Description: 
# The root is currently org.apache.metrics. I would expect the product name to 
be included (so org.apache.ignite.metrics)
 # It is technically possible to run more than one Ignite node in the same JVM. 
Only the first node will register its MBeans, others will fail to export using 
JMX. It does not seem to be a production mode of using Ignite, but this needs 
to be checked: maybe we should include node name in the root name

> Sort out JMX exporter MBeans root issues
> 
>
> Key: IGNITE-22196
> URL: https://issues.apache.org/jira/browse/IGNITE-22196
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> # The root is currently org.apache.metrics. I would expect the product name 
> to be included (so org.apache.ignite.metrics)
>  # It is technically possible to run more than one Ignite node in the same 
> JVM. Only the first node will register its MBeans, others will fail to export 
> using JMX. It does not seem to be a production mode of using Ignite, but this 
> needs to be checked: maybe we should include node name in the root name



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails on macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Description: 
NettyServerTest::testBindWithAddress fails with the following error on macOS:


{noformat}
at 
org.apache.ignite.internal.network.netty.NettyServerTest.testBindWithAddress(NettyServerTest.java:163)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: org.opentest4j.AssertionFailedError
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:46)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:161)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
at 
org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
... 6 more
Caused by: java.util.concurrent.ExecutionException: 
org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
... 8 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at 
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
at 
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
at 
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
at 
io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
at 
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.net.BindException: Can't assign requested address
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:459)
at java.base/sun.nio.ch.Net.bind(Net.java:448)
at 
java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at 
io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562)
{noformat}



  was:
NettyServerTest::testBindWithAddress fails with the following error on macOS:


{noformat}
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
at 
org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
... 6 more
Caused by: 

[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Summary: NettyServerTest::testBindWithAddress fails to macOS because 
network address used in the test case is not available  (was: 
NettyServerTest::testBindWithAddress fails to macOs because network address 
used in the test case is not available)

> NettyServerTest::testBindWithAddress fails to macOS because network address 
> used in the test case is not available
> --
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> NettyServerTest::testBindWithAddress fails with the following error on macOs:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
> ... 8 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> 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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at 
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at 
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at 
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Can't assign requested address
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Labels: ignite-3  (was: )

> NettyServerTest::testBindWithAddress fails to macOS because network address 
> used in the test case is not available
> --
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>  Labels: ignite-3
>
> NettyServerTest::testBindWithAddress fails with the following error on macOS:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
> ... 8 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> 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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at 
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at 
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at 
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Can't assign requested address
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (IGNITE-22186) Make JvmMetricSource conform to the rules of IEP-116

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy resolved IGNITE-22186.

Resolution: Not A Problem

It turned out that it was agreed to allow such naming when doing otherwise 
causes too much trouble. It was planned to update the IEP.

> Make JvmMetricSource conform to the rules of IEP-116
> 
>
> Key: IGNITE-22186
> URL: https://issues.apache.org/jira/browse/IGNITE-22186
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> [IEP-116|[https://cwiki.apache.org/confluence/display/IGNITE/IEP-116%3A+Metrics]]
>  says that a metric source name may have structure delimited by period 
> characters, but metric names cannot have such a structure.
> JvmMetricSource behaves differently: its metrics have an hierarchicat 
> structure.
> This needs to be sorted out.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOs because network address used in the test case is not available.

2024-05-08 Thread Maksim Zhuravkov (Jira)
Maksim Zhuravkov created IGNITE-22195:
-

 Summary: NettyServerTest::testBindWithAddress fails to macOs 
because network address used in the test case is not available.
 Key: IGNITE-22195
 URL: https://issues.apache.org/jira/browse/IGNITE-22195
 Project: Ignite
  Issue Type: Bug
Reporter: Maksim Zhuravkov


NettyServerTest::testBindWithAddress fails with the following error on macOs:



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails on macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Summary: NettyServerTest::testBindWithAddress fails on macOS because 
network address used in the test case is not available  (was: 
NettyServerTest::testBindWithAddress fails to macOS because network address 
used in the test case is not available)

> NettyServerTest::testBindWithAddress fails on macOS because network address 
> used in the test case is not available
> --
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>  Labels: ignite-3
>
> NettyServerTest::testBindWithAddress fails with the following error on macOS:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
> ... 8 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> 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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at 
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at 
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at 
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Can't assign requested address
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22196) Sort out JMX exporter MBeans root issues

2024-05-08 Thread Roman Puchkovskiy (Jira)
Roman Puchkovskiy created IGNITE-22196:
--

 Summary: Sort out JMX exporter MBeans root issues
 Key: IGNITE-22196
 URL: https://issues.apache.org/jira/browse/IGNITE-22196
 Project: Ignite
  Issue Type: Improvement
Reporter: Roman Puchkovskiy






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> NettyServerTest::testBindWithAddress fails to macOS because network address 
> used in the test case is not available
> --
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>  Labels: ignite-3
>
> NettyServerTest::testBindWithAddress fails with the following error on macOS:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
> ... 8 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> 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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at 
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at 
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at 
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Can't assign requested address
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOs because network address used in the test case is not available.

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Description: 
NettyServerTest::testBindWithAddress fails with the following error on macOs:


{noformat}
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
at 
org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
... 6 more
Caused by: java.util.concurrent.ExecutionException: 
org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
... 8 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at 
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
at 
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
at 
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
at 
io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
at 
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.net.BindException: Can't assign requested address

{noformat}



  was:NettyServerTest::testBindWithAddress fails with the following error on 
macOs:


> NettyServerTest::testBindWithAddress fails to macOs because network address 
> used in the test case is not available.
> ---
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> NettyServerTest::testBindWithAddress fails with the following error on macOs:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
>   

[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOS because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Description: 
NettyServerTest::testBindWithAddress fails with the following error on macOS:


{noformat}
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
at 
org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
... 6 more
Caused by: java.util.concurrent.ExecutionException: 
org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
... 8 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at 
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
at 
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
at 
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
at 
io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
at 
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.net.BindException: Can't assign requested address

{noformat}



  was:
NettyServerTest::testBindWithAddress fails with the following error on macOs:


{noformat}
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
at 
org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
... 6 more
Caused by: java.util.concurrent.ExecutionException: 
org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
at 
org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
... 8 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
available
at 
org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at 
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
at 

[jira] [Updated] (IGNITE-22195) NettyServerTest::testBindWithAddress fails to macOs because network address used in the test case is not available

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22195:
--
Summary: NettyServerTest::testBindWithAddress fails to macOs because 
network address used in the test case is not available  (was: 
NettyServerTest::testBindWithAddress fails to macOs because network address 
used in the test case is not available.)

> NettyServerTest::testBindWithAddress fails to macOs because network address 
> used in the test case is not available
> --
>
> Key: IGNITE-22195
> URL: https://issues.apache.org/jira/browse/IGNITE-22195
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
>
> NettyServerTest::testBindWithAddress fails with the following error on macOs:
> {noformat}
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:315)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.lambda$testBindWithAddress$2(NettyServerTest.java:163)
> at 
> org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:71)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: 
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at 
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at 
> org.apache.ignite.internal.network.netty.NettyServerTest.getServer(NettyServerTest.java:312)
> ... 8 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:2a7ec890-127e-4da8-847b-376538afe064 Address 127.0.0.7:47500 is not 
> available
> at 
> org.apache.ignite.internal.network.netty.NettyServer.lambda$start$0(NettyServer.java:159)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> at 
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> 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.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:999)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:564)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:600)
> at 
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:579)
> at 
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260)
> at 
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:380)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Can't assign requested address
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22194:
--
Fix Version/s: 3.0.0-beta2

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22194:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22194:
--
Description: 
PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
fails start because of that.


  was:
PlatformBenchmarkNodeRunner use portRange property that no longer exist and 
fails start because of that.



> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
>
> PlatformBenchmarkNodeRunner uses portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exists

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22194:
--
Summary: PlatformBenchmarkNodeRunner fails to start because it uses 
configuration property that no longer exists  (was: PlatformBenchmarkNodeRunner 
fails to start because it uses configuration property that no longer exist)

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exists
> ---
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
>
> PlatformBenchmarkNodeRunner use portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exist

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov reassigned IGNITE-22194:
-

Assignee: Maksim Zhuravkov

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exist
> --
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
>
> PlatformBenchmarkNodeRunner use portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exist

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22194:
--
Labels: ignite-3  (was: )

> PlatformBenchmarkNodeRunner fails to start because it uses configuration 
> property that no longer exist
> --
>
> Key: IGNITE-22194
> URL: https://issues.apache.org/jira/browse/IGNITE-22194
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Trivial
>  Labels: ignite-3
>
> PlatformBenchmarkNodeRunner use portRange property that no longer exist and 
> fails start because of that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22194) PlatformBenchmarkNodeRunner fails to start because it uses configuration property that no longer exist

2024-05-08 Thread Maksim Zhuravkov (Jira)
Maksim Zhuravkov created IGNITE-22194:
-

 Summary: PlatformBenchmarkNodeRunner fails to start because it 
uses configuration property that no longer exist
 Key: IGNITE-22194
 URL: https://issues.apache.org/jira/browse/IGNITE-22194
 Project: Ignite
  Issue Type: Bug
Reporter: Maksim Zhuravkov


PlatformBenchmarkNodeRunner use portRange property that no longer exist and 
fails start because of that.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22193) Move IgniteJdbcDriver to non internal package

2024-05-08 Thread Iurii Gerzhedovich (Jira)
Iurii Gerzhedovich created IGNITE-22193:
---

 Summary: Move IgniteJdbcDriver to non internal package
 Key: IGNITE-22193
 URL: https://issues.apache.org/jira/browse/IGNITE-22193
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Iurii Gerzhedovich


Right now we have org.apache.ignite.internal.jdbc.IgniteJdbcDriver which is 
placed in `internal' package. Most database utilities working with JDBC drivers 
show the name to users, e.g. DBeaver.
This approach is not user-friendly. Let's move the class to 
`org.apache.ignite.jdbc` package



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-21942) Cover SQL F393(Unicode escapes in literals) feature by tests

2024-05-08 Thread Andrey Mashenkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Mashenkov reassigned IGNITE-21942:
-

Assignee: Andrey Mashenkov

> Cover SQL F393(Unicode escapes in literals) feature by tests
> 
>
> Key: IGNITE-21942
> URL: https://issues.apache.org/jira/browse/IGNITE-21942
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
>
> We don't have at all any tests for F393(Unicode escapes in literals) SQL 
> feature.
> Let's cover it and create tickets to fix them in case find any issues related 
> to the covered area



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick

2024-05-08 Thread Julia Bakulina (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julia Bakulina reassigned IGNITE-22089:
---

Assignee: Julia Bakulina

> Removal of MVCC benchmarks in Yardstick
> ---
>
> Key: IGNITE-22089
> URL: https://issues.apache.org/jira/browse/IGNITE-22089
> Project: Ignite
>  Issue Type: Sub-task
>  Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
>
> AbstractDistributedMvccBenchmark
> MvccProcessorBenchmark
> MvccUpdateContentionBenchmark



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22178) Fix checkStyle ignite-extensions

2024-05-08 Thread Nikita Amelchev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikita Amelchev updated IGNITE-22178:
-
Fix Version/s: (was: 2.17)

> Fix checkStyle ignite-extensions
> 
>
> Key: IGNITE-22178
> URL: https://issues.apache.org/jira/browse/IGNITE-22178
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Minor
>  Labels: ise
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22178) Fix checkStyle ignite-extensions

2024-05-08 Thread Nikita Amelchev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikita Amelchev updated IGNITE-22178:
-
Component/s: extensions

> Fix checkStyle ignite-extensions
> 
>
> Key: IGNITE-22178
> URL: https://issues.apache.org/jira/browse/IGNITE-22178
> Project: Ignite
>  Issue Type: Improvement
>  Components: extensions
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Minor
>  Labels: ise
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (IGNITE-22178) Fix checkStyle ignite-extensions

2024-05-08 Thread Nikita Amelchev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikita Amelchev resolved IGNITE-22178.
--
Resolution: Fixed

Merged into the master.

[~aonikolaev], Thank you for the contribution!

> Fix checkStyle ignite-extensions
> 
>
> Key: IGNITE-22178
> URL: https://issues.apache.org/jira/browse/IGNITE-22178
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Minor
>  Labels: ise
> Fix For: 2.17
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-19082) Catalog. Cleanup dead code.

2024-05-08 Thread Andrey Mashenkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Mashenkov updated IGNITE-19082:
--
Description: 
Let's
 * ensure Catalog is used by default as a single schema management point by 
TableManager, IndexManager, SqlSchemaManager, SchemaRegistry.
 * -drop schema related code from configuration.-
 * -drop outdated code from TableManager, IndexManager, SqlSchemaManager, 
SchemaRegistry.-
 * Let’s remove using/keeping schema name instead of schema id (NewIndexEntry 
class as example)

  was:
Let's
 * ensure Catalog is used by default as a single schema management point by 
TableManager, IndexManager, SqlSchemaManager, SchemaRegistry.
 * drop schema related code from configuration.
 * drop outdated code from TableManager, IndexManager, SqlSchemaManager, 
SchemaRegistry.
 * make a PR for merging feature branch to main (if applicable).
 * ensure there are end-to-end tests for the cases (if applicable) described in 
CatalogServiceSelfTest. Also drop InternalSchemaTest.
 * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry 
class as example)


> Catalog. Cleanup dead code.
> ---
>
> Key: IGNITE-19082
> URL: https://issues.apache.org/jira/browse/IGNITE-19082
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Let's
>  * ensure Catalog is used by default as a single schema management point by 
> TableManager, IndexManager, SqlSchemaManager, SchemaRegistry.
>  * -drop schema related code from configuration.-
>  * -drop outdated code from TableManager, IndexManager, SqlSchemaManager, 
> SchemaRegistry.-
>  * Let’s remove using/keeping schema name instead of schema id (NewIndexEntry 
> class as example)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22135) Sql. Investigate get ride support of CHAR datatype.

2024-05-08 Thread Konstantin Orlov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Orlov reassigned IGNITE-22135:
-

Assignee: Konstantin Orlov

> Sql. Investigate get ride support of CHAR datatype.
> ---
>
> Key: IGNITE-22135
> URL: https://issues.apache.org/jira/browse/IGNITE-22135
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
>  Labels: ignite-3
>
> CHAR type is not widely used by users, however, the type has specific need to 
> be supported and requires significant time to do it right.
> Let's consider the ability to get rid of the type.
> List possibility solutions ordered by priority:
> 1. Make CHAR type an alias for VARCHAR, but take into account that in the 
> future we can start supporting the type in the right way and need to be sure 
> we can support smooth migration from the version that does not support CHAR 
> to the new one with such support ( as example - metadata for such type should 
> reflect real type VARCHAR)
> 2. Forbid CHAR type at all. No alias even.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-21950) Cover SQL T351(Bracketed SQL comments (/*...*/ comments)) feature by tests

2024-05-08 Thread Konstantin Orlov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Orlov updated IGNITE-21950:
--
Fix Version/s: 3.0.0-beta2

> Cover SQL T351(Bracketed SQL comments (/*...*/ comments)) feature by tests
> --
>
> Key: IGNITE-21950
> URL: https://issues.apache.org/jira/browse/IGNITE-21950
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We don't have at all any tests for T351(Bracketed SQL comments (/*...*/ 
> comments)) SQL feature.
> Let's cover it and create tickets to fix them in case find any issues related 
> to the covered area



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22188) Add metrics for debugging ItSqlLogicTest

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-22188:
---
Description: 
* jvm.gc..CollectionCount (long gauge)
 * jvm.gc..CollectionTime (long gauge)
 * os.LoadAverage (long gauge, LA from the OS)
 * metastorage.SafeTimeLag (long gauge,  number of milliseconds between local 
HLC and local Metastorage SafeTime)

> Add metrics for debugging ItSqlLogicTest
> 
>
> Key: IGNITE-22188
> URL: https://issues.apache.org/jira/browse/IGNITE-22188
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> * jvm.gc..CollectionCount (long gauge)
>  * jvm.gc..CollectionTime (long gauge)
>  * os.LoadAverage (long gauge, LA from the OS)
>  * metastorage.SafeTimeLag (long gauge,  number of milliseconds between local 
> HLC and local Metastorage SafeTime)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22192) Metric exporters are started twice

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-22192:
---
Description: If logPush exporter is enabled in the configuration, it gets 
started twice. This seems to happen because exporters are first started during 
MetricManager start, and then, as a reaction to configuration update (which 
happens a bit later, in IgniteImpl#recoverComponentsStateOnStart().

> Metric exporters are started twice
> --
>
> Key: IGNITE-22192
> URL: https://issues.apache.org/jira/browse/IGNITE-22192
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> If logPush exporter is enabled in the configuration, it gets started twice. 
> This seems to happen because exporters are first started during MetricManager 
> start, and then, as a reaction to configuration update (which happens a bit 
> later, in IgniteImpl#recoverComponentsStateOnStart().



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22192) Metric exporters are started twice

2024-05-08 Thread Roman Puchkovskiy (Jira)
Roman Puchkovskiy created IGNITE-22192:
--

 Summary: Metric exporters are started twice
 Key: IGNITE-22192
 URL: https://issues.apache.org/jira/browse/IGNITE-22192
 Project: Ignite
  Issue Type: Bug
Reporter: Roman Puchkovskiy






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-19091) Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. AssertError: Token must be greater than actual [token=4, actual=4]

2024-05-08 Thread Iurii Gerzhedovich (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-19091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Iurii Gerzhedovich updated IGNITE-19091:

Labels: ignite-3  (was: calcite3-required ignite-3)

> Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. 
> AssertError: Token must be greater than actual [token=4, actual=4]
> -
>
> Key: IGNITE-19091
> URL: https://issues.apache.org/jira/browse/IGNITE-19091
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> After implementation of https://issues.apache.org/jira/browse/IGNITE-18225 
> ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart fails with an 
> error in code that processes table creation event: 
> .engine.schema.SqlSchemaManagerImpl.onTableCreated.
> AssertionError:
> {code:java}
> 2023-03-22 11:58:12:859 +0400 
> [WARNING][MessagingService-inbound-0][TableManager] Error occurred while 
> updating tables.
> java.util.concurrent.CompletionException: java.lang.AssertionError: Token 
> must be greater than actual [token=4, actual=4]
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.completeInternal(VersionedValue.java:323)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.lambda$completeOnRevision$4(VersionedValue.java:483)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$38(RaftGroupServiceImpl.java:525)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:363)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:328)
>   at 
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$3(DefaultMessagingService.java:306)
>   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: Token must be greater than actual 
> [token=4, actual=4]
>   at 
> org.apache.ignite.internal.causality.VersionedValue.checkToken(VersionedValue.java:580)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.update(VersionedValue.java:393)
>   at 
> org.apache.ignite.internal.sql.engine.schema.SqlSchemaManagerImpl.onTableCreated(SqlSchemaManagerImpl.java:218)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:583)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:575)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:108)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:129)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$36(TableManager.java:1183)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:870)
>   at 
> 

[jira] [Updated] (IGNITE-22190) ItClusterManagerTest refactoring

2024-05-08 Thread Aleksandr Polovtsev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtsev updated IGNITE-22190:
-
Description: This test and code around it is old and can be updated to be 
shorter and more concise.

> ItClusterManagerTest refactoring
> 
>
> Key: IGNITE-22190
> URL: https://issues.apache.org/jira/browse/IGNITE-22190
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This test and code around it is old and can be updated to be shorter and more 
> concise.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22190) ItClusterManagerTest refactoring

2024-05-08 Thread Aleksandr Polovtsev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtsev updated IGNITE-22190:
-
Fix Version/s: 3.0.0-beta2

> ItClusterManagerTest refactoring
> 
>
> Key: IGNITE-22190
> URL: https://issues.apache.org/jira/browse/IGNITE-22190
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This test and code around it is old and can be updated to be shorter and more 
> concise.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22191) Fix AssertionError in IndexBuildController#mvPartitionStorage

2024-05-08 Thread Kirill Tkalenko (Jira)
Kirill Tkalenko created IGNITE-22191:


 Summary: Fix AssertionError in 
IndexBuildController#mvPartitionStorage
 Key: IGNITE-22191
 URL: https://issues.apache.org/jira/browse/IGNITE-22191
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 3.0.0-beta2


Need to fix the error by stacktrace:
{noformat}
[2024-05-07T15:31:12,023][ERROR][%irt_trtcfz_0%metastorage-watch-executor-3][FailureProcessor]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=NoOpFailureHandler [], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=java.lang.AssertionError: 8_part_1]]
java.lang.AssertionError: 8_part_1
at 
org.apache.ignite.internal.index.IndexBuildController.mvPartitionStorage(IndexBuildController.java:345)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.index.IndexBuildController.scheduleBuildIndexAfterDisasterRecovery(IndexBuildController.java:314)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.index.IndexBuildController.lambda$tryScheduleBuildIndexesForNewPrimaryReplica$14(IndexBuildController.java:219)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:869) 
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.index.IndexBuildController.tryScheduleBuildIndexesForNewPrimaryReplica(IndexBuildController.java:208)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.index.IndexBuildController.lambda$onPrimaryReplicaElected$11(IndexBuildController.java:187)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
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.index.IndexBuildController.lambda$onPrimaryReplicaElected$12(IndexBuildController.java:187)
 ~[ignite-index-3.0.0-SNAPSHOT.jar:?]
at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
 ~[?:?]
at 
org.apache.ignite.internal.util.IgniteUtils.lambda$copyStateTo$9(IgniteUtils.java:1273)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
 ~[?:?]
at 
org.apache.ignite.internal.causality.BaseVersionedValue.copyState(BaseVersionedValue.java:315)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.causality.BaseVersionedValue.complete(BaseVersionedValue.java:201)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.causality.IncrementalVersionedValue.lambda$completeInternal$2(IncrementalVersionedValue.java:256)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
 ~[?:?]
at 
org.apache.ignite.internal.causality.IncrementalVersionedValue.completeInternal(IncrementalVersionedValue.java:256)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.causality.IncrementalVersionedValue.lambda$dependingOn$0(IncrementalVersionedValue.java:76)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.causality.BaseVersionedValue.lambda$notifyCompletionListeners$6(BaseVersionedValue.java:337)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
 ~[?:?]
at 
java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
 ~[?:?]
at 
org.apache.ignite.internal.causality.BaseVersionedValue.notifyCompletionListeners(BaseVersionedValue.java:332)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.internal.causality.BaseVersionedValue.complete(BaseVersionedValue.java:210)
 ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
{noformat}




--
This message was sent 

[jira] [Created] (IGNITE-22190) ItClusterManagerTest refactoring

2024-05-08 Thread Aleksandr Polovtsev (Jira)
Aleksandr Polovtsev created IGNITE-22190:


 Summary: ItClusterManagerTest refactoring
 Key: IGNITE-22190
 URL: https://issues.apache.org/jira/browse/IGNITE-22190
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksandr Polovtsev
Assignee: Aleksandr Polovtsev






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22189) Display Expiry Policy information in the system view

2024-05-08 Thread Maksim Davydov (Jira)
Maksim Davydov created IGNITE-22189:
---

 Summary: Display Expiry Policy information in the system view
 Key: IGNITE-22189
 URL: https://issues.apache.org/jira/browse/IGNITE-22189
 Project: Ignite
  Issue Type: Improvement
Reporter: Maksim Davydov
Assignee: Maksim Davydov


The {{CacheView#expiryPolicyFactory}} method returns the ExpiryPolicyFactory 
string representation, which at this point is a simple className +@ + hashCode 
in hex, that is default {{Object#toString()}} behaviour. This is not 
informative for an end user of the API.

In addition, it is useful to have information about existing cache entries that 
are about to expire (eligible for cache expiry policy).

{*}TODO{*}:
 * To make the {{CacheView#expiryPolicyFactory}} method return readable, 
human-oriented output, one should refactor the method or 
{{Factory}} child classes to provide the cache expiry policy 
setting in readable form with policy type and ttl.
* Within the cache group view ({{CacheGroupView}}), check the entries presence 
eligible for expiry policy. It can be done with O(1) time complexity for 
in-memory, and O(number of partitions) for persistent mode.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22188) Add metrics for debugging ItSqlLogicTest

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy reassigned IGNITE-22188:
--

Assignee: Roman Puchkovskiy

> Add metrics for debugging ItSqlLogicTest
> 
>
> Key: IGNITE-22188
> URL: https://issues.apache.org/jira/browse/IGNITE-22188
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22188) Add metrics for debugging ItSqlLogicTest

2024-05-08 Thread Roman Puchkovskiy (Jira)
Roman Puchkovskiy created IGNITE-22188:
--

 Summary: Add metrics for debugging ItSqlLogicTest
 Key: IGNITE-22188
 URL: https://issues.apache.org/jira/browse/IGNITE-22188
 Project: Ignite
  Issue Type: Improvement
Reporter: Roman Puchkovskiy
 Fix For: 3.0.0-beta2






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844600#comment-17844600
 ] 

Pavel Pereslegin commented on IGNITE-22061:
---

The easiest way is to use {{stripTrailingZeros}} (similar to what is done in 
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up 
with a more efficient estimation.

> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the 
> pre-allocated buffer to be significantly larger than required.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22148) BinaryTupleFormatException for UUID

2024-05-08 Thread Iurii Gerzhedovich (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Iurii Gerzhedovich updated IGNITE-22148:

Description: 
Simple example to reproduce the issue:
{code:java}
sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a) 
)"); 
sql("insert into tdd(b) values(22)");{code}
we got
{code:java}
Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException: 
IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for a 
tuple element: 36
    at 
org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
    at 
org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
    at 
org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
    at 
org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
    at 
org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
    at 
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
    at 
org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
    at 
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
 {code}


Let's add validation for `create table` at least for defaults

  was:
Simple example to reproduce the issue:
{code:java}
sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a) 
)"); 
sql("insert into tdd(b) values(22)");{code}
we got
{code:java}
Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException: 
IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for a 
tuple element: 36
    at 
org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
    at 
org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
    at 
org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
    at 
org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
    at 
org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
    at 
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
    at 
org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
    at 
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
 {code}


> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>  Labels: ignite-3
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a) 
> )"); 
> sql("insert into tdd(b) values(22)");{code}
> we got
> {code:java}
> Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException: 
> IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for 
> a tuple element: 36
>     at 
> org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
>     at 
> org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
>     at 
> org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
>     at 
> org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
>     at 
> org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
>     at 
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
>     at 
> org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
>     at 
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
>  {code}
> Let's add validation for `create table` at least for defaults



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22160) Sql. Usability of error message in case of numeric overflow

2024-05-08 Thread Iurii Gerzhedovich (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Iurii Gerzhedovich updated IGNITE-22160:

Description: 
Let's consider error messages for the following queries:
SELECT '1'::DECIMAL(3, 3)::VARCHAR;
SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
SELECT '0.1'::DECIMAL(3, 4);

Right now the queries expected to fail, but we have not so user-friendly error 
messages like a
{code:java}
 IGN-SQL-9 TraceId:0460f382-120f-49a4-9ee2-e09ee90d4764 Numeric field 
overflow{code}
For example, an error in PG looks so (seems need to look alternative in 
different DBs):
{code:java}
ERROR: numeric field overflow DETAIL: A field with precision 3, scale 4 must 
round to an absolute value less than 10^-1.
 
{code}
Let's improve error messages.

Start point is using of
{code:java}
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator#NUMERIC_FIELD_OVERFLOW_ERROR{code}

  was:
Let's consider error messages for the following queries:
SELECT '1'::DECIMAL(3, 3)::VARCHAR;
SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
SELECT '0.1'::DECIMAL(3, 4);

Right now the queries expected to fail, but we have not so user-friendly error 
messages like a
{code:java}
 IGN-SQL-9 TraceId:0460f382-120f-49a4-9ee2-e09ee90d4764 Numeric field 
overflow{code}
For example, an error in PG looks so:
{code:java}
ERROR: numeric field overflow DETAIL: A field with precision 3, scale 4 must 
round to an absolute value less than 10^-1.
 
{code}

Let's improve error messages.

Start point is using of
{code:java}
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator#NUMERIC_FIELD_OVERFLOW_ERROR{code}


> Sql. Usability of error message in case of numeric overflow 
> 
>
> Key: IGNITE-22160
> URL: https://issues.apache.org/jira/browse/IGNITE-22160
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>  Labels: ignite-3
>
> Let's consider error messages for the following queries:
> SELECT '1'::DECIMAL(3, 3)::VARCHAR;
> SELECT '-1'::DECIMAL(3, 3)::VARCHAR;
> SELECT '0.1'::DECIMAL(3, 4);
> Right now the queries expected to fail, but we have not so user-friendly 
> error messages like a
> {code:java}
>  IGN-SQL-9 TraceId:0460f382-120f-49a4-9ee2-e09ee90d4764 Numeric field 
> overflow{code}
> For example, an error in PG looks so (seems need to look alternative in 
> different DBs):
> {code:java}
> ERROR: numeric field overflow DETAIL: A field with precision 3, scale 4 must 
> round to an absolute value less than 10^-1.
>  
> {code}
> Let's improve error messages.
> Start point is using of
> {code:java}
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator#NUMERIC_FIELD_OVERFLOW_ERROR{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (IGNITE-22139) JDBC request to degraded cluster freezes forever

2024-05-08 Thread Igor (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor resolved IGNITE-22139.
---
Resolution: Cannot Reproduce

> JDBC request to degraded cluster freezes forever
> 
>
> Key: IGNITE-22139
> URL: https://issues.apache.org/jira/browse/IGNITE-22139
> Project: Ignite
>  Issue Type: Bug
>  Components: general, jdbc, networking, persistence
>Affects Versions: 3.0.0-beta1
> Environment: The 2 or 3 nodes cluster running locally.
>Reporter: Igor
>Priority: Major
>  Labels: ignite-3
>
> *Steps to reproduce:*
>  # Create zone with replication equals to amount of nodes (2 or 3 
> corresponding)
>  # Create 10 tables inside the zone.
>  # Insert 100 rows in every table.
>  # Await all tables*partitions*nodes local state is "HEALTHY"
>  # Await all tables*partitions*nodes global state is "AVAILABLE"
>  # Kill first node with kill -9.
>  # Assert all tables*partitions*nodes local state is "HEALTHY"
>  # Await all tables*partitions*nodes global state is "READ_ONLY" for 2 nodes 
> cluster or "DEGRADED" for 3 nodes cluster,
>  # Execute select query using JDBC connecting to the second node (which is 
> alive).
> *Expected:*
> Data is returned.
> *Actual:*
> The select query at step 9 freezes forever.
> The errors on the server side:
> {code:java}
> 2024-04-30 00:04:02:965 +0200 
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][AbstractClientService]
>  Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
> java.util.concurrent.TimeoutException.
> 2024-04-30 00:04:02:965 +0200 
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][ReplicatorGroupImpl]
>  Fail to check replicator connection to 
> peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
> 2024-04-30 00:04:02:980 +0200 
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][AbstractClientService]
>  Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
> java.util.concurrent.TimeoutException.
> 2024-04-30 00:04:02:980 +0200 
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][ReplicatorGroupImpl]
>  Fail to check replicator connection to 
> peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
> 2024-04-30 00:04:02:981 +0200 
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][NodeImpl]
>  Fail to add a replicator, peer=ClusterFailover3NodesTest_cluster_0.
> 2024-04-30 00:04:02:981 +0200 
> [WARNING][ClusterFailover3NodesTest_cluster_1-client-8][RaftGroupServiceImpl] 
> Recoverable error during the request occurred (will be retried on the 
> randomly selected node) [request=WriteActionRequestImpl [command=[0, 9, 41, 
> -117, -128, -8, -15, -83, -4, -54, -57, 1], 
> deserializedCommand=SafeTimeSyncCommandImpl 
> [safeTimeLong=112356769098760202], groupId=26_part_10], peer=Peer 
> [consistentId=ClusterFailover3NodesTest_cluster_0, idx=0], newPeer=Peer 
> [consistentId=ClusterFailover3NodesTest_cluster_1, idx=0]].
> java.util.concurrent.CompletionException: 
> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection 
> refused: no further information: /192.168.100.5:3344
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> org.apache.ignite.internal.network.netty.NettyUtils.lambda$toCompletableFuture$0(NettyUtils.java:74)
>   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:326)
>   at 
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:342)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776)
>   at 
> 

[jira] [Updated] (IGNITE-22171) Sql. Row cast fails with NPE.

2024-05-08 Thread Maksim Zhuravkov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maksim Zhuravkov updated IGNITE-22171:
--
Priority: Minor  (was: Major)

> Sql. Row cast fails with NPE.
> -
>
> Key: IGNITE-22171
> URL: https://issues.apache.org/jira/browse/IGNITE-22171
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Minor
>  Labels: ignite-3
>
> {noformat}
> SELECT * FROM (VALUES ROW(CAST(ROW(1, 2.0) AS ROW(x BIGINT, y DOUBLE;
> {noformat}
> {noformat}
> Caused by: java.lang.NullPointerException: SqlTypeFamily for 
> RecordType(BIGINT X, DOUBLE Y)
>   at java.base/java.util.Objects.requireNonNull(Objects.java:349)
>   at 
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:1055)
>   at 
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateCast(RexToLixTranslator.java:689)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22186) Make JvmMetricSource conform to the rules of IEP-116

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-22186:
---
Summary: Make JvmMetricSource conform to the rules of IEP-116  (was: Make 
JvmMetricSource confirm to the rules of IEP-116)

> Make JvmMetricSource conform to the rules of IEP-116
> 
>
> Key: IGNITE-22186
> URL: https://issues.apache.org/jira/browse/IGNITE-22186
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> [IEP-116|[https://cwiki.apache.org/confluence/display/IGNITE/IEP-116%3A+Metrics]]
>  says that a metric source name may have structure delimited by period 
> characters, but metric names cannot have such a structure.
> JvmMetricSource behaves differently: its metrics have an hierarchicat 
> structure.
> This needs to be sorted out.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22187) Cluster of 2 or 3 nodes doesn't work if one node is down

2024-05-08 Thread Igor (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor updated IGNITE-22187:
--
Description: 
*Steps to reproduce:*
 # Create zone with replication equals to amount of nodes (2 or 3 corresponding)
 # Create 10 tables inside the zone.
 # Insert 100 rows in every table.
 # Await all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "AVAILABLE"
 # Kill first node with kill -9.
 # Assert all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "READ_ONLY" for 2 nodes 
cluster or "DEGRADED" for 3 nodes cluster,
 # Execute select query using JDBC connecting to the second node (which is 
alive).

*Expected:*

Data is returned.

*Actual:*
On the step 7 it returns error by REST API:
{code:java}
{"title":"Internal Server 
Error","status":500,"code":"IGN-RECOVERY-3","type":null,"detail":"io.netty.channel.AbstractChannel$AnnotatedConnectException:
 Connection refused: 
/172.120.6.2:3344","node":null,"traceId":"2acb52fc-3275-411b-a4de-45f14873f15c","invalidParams":null}{code}
In the server logs continuous errors:
{code:java}
2024-05-08 10:37:19:796 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-9][AbstractClientService]
 Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
java.net.ConnectException.
2024-05-08 10:37:19:796 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-9][ReplicatorGroupImpl]
 Fail to check replicator connection to 
peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
2024-05-08 10:37:19:796 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-12][AbstractClientService]
 Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
java.net.ConnectException.
2024-05-08 10:37:19:796 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-12][ReplicatorGroupImpl]
 Fail to check replicator connection to 
peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower. {code}
If skip steps 7 and 8, then the exception on step 9 occurs:
{code:java}
java.sql.SQLException: Unable to send fragment 
[targetNode=ClusterFailover3NodesTest_cluster_0, fragmentId=1, 
cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection 
refused: no further information: /192.168.100.5:3344]
    at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
    at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
    at 
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111)
    at 
org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:91)
    at 
org.gridgain.ai3tests.tests.failover.ClusterFailoverTestBase.getActualResult(ClusterFailoverTestBase.java:336)
    at 
org.gridgain.ai3tests.tests.failover.ClusterFailoverTestBase.assertDataIsFilledWithoutErrors(ClusterFailoverTestBase.java:154)
    at 
org.gridgain.ai3tests.tests.failover.ClusterFailover3NodesTest.singleKillAndCheckOtherNodeWorks(ClusterFailover3NodesTest.java:96)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834) {code}

  was:
*Steps to reproduce:*
 # Create zone with replication equals to amount of nodes (2 or 3 corresponding)
 # Create 10 tables inside the zone.
 # Insert 100 rows in every table.
 # Await all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "AVAILABLE"
 # Kill first node with kill -9.
 # Assert all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "READ_ONLY" for 2 nodes 
cluster or "DEGRADED" for 3 nodes cluster,
 # Execute select query using JDBC connecting to the second node (which is 
alive).

*Expected:*

Data is returned.

*Actual:*
The select query at step 9 freezes forever.
The errors on the server side:
{code:java}
2024-04-30 00:04:02:965 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][AbstractClientService]
 Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
java.util.concurrent.TimeoutException.
2024-04-30 00:04:02:965 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][ReplicatorGroupImpl]
 Fail to check replicator connection to 
peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
2024-04-30 00:04:02:980 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][AbstractClientService]
 Fail to connect 

[jira] [Created] (IGNITE-22187) Cluster of 2 or 3 nodes doesn't work if one node is down

2024-05-08 Thread Igor (Jira)
Igor created IGNITE-22187:
-

 Summary: Cluster of 2 or 3 nodes doesn't work if one node is down
 Key: IGNITE-22187
 URL: https://issues.apache.org/jira/browse/IGNITE-22187
 Project: Ignite
  Issue Type: Bug
  Components: general, jdbc, networking, persistence
Affects Versions: 3.0.0-beta1
 Environment: The 2 or 3 nodes cluster running locally.
Reporter: Igor


*Steps to reproduce:*
 # Create zone with replication equals to amount of nodes (2 or 3 corresponding)
 # Create 10 tables inside the zone.
 # Insert 100 rows in every table.
 # Await all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "AVAILABLE"
 # Kill first node with kill -9.
 # Assert all tables*partitions*nodes local state is "HEALTHY"
 # Await all tables*partitions*nodes global state is "READ_ONLY" for 2 nodes 
cluster or "DEGRADED" for 3 nodes cluster,
 # Execute select query using JDBC connecting to the second node (which is 
alive).

*Expected:*

Data is returned.

*Actual:*
The select query at step 9 freezes forever.
The errors on the server side:
{code:java}
2024-04-30 00:04:02:965 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][AbstractClientService]
 Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
java.util.concurrent.TimeoutException.
2024-04-30 00:04:02:965 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-8][ReplicatorGroupImpl]
 Fail to check replicator connection to 
peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
2024-04-30 00:04:02:980 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][AbstractClientService]
 Fail to connect ClusterFailover3NodesTest_cluster_0, exception: 
java.util.concurrent.TimeoutException.
2024-04-30 00:04:02:980 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][ReplicatorGroupImpl]
 Fail to check replicator connection to 
peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
2024-04-30 00:04:02:981 +0200 
[ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-Response-Processor-1][NodeImpl]
 Fail to add a replicator, peer=ClusterFailover3NodesTest_cluster_0.
2024-04-30 00:04:02:981 +0200 
[WARNING][ClusterFailover3NodesTest_cluster_1-client-8][RaftGroupServiceImpl] 
Recoverable error during the request occurred (will be retried on the randomly 
selected node) [request=WriteActionRequestImpl [command=[0, 9, 41, -117, -128, 
-8, -15, -83, -4, -54, -57, 1], deserializedCommand=SafeTimeSyncCommandImpl 
[safeTimeLong=112356769098760202], groupId=26_part_10], peer=Peer 
[consistentId=ClusterFailover3NodesTest_cluster_0, idx=0], newPeer=Peer 
[consistentId=ClusterFailover3NodesTest_cluster_1, idx=0]].
java.util.concurrent.CompletionException: 
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: 
no further information: /192.168.100.5:3344
  at 
java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
  at 
java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
  at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
  at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
  at 
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
  at 
org.apache.ignite.internal.network.netty.NettyUtils.lambda$toCompletableFuture$0(NettyUtils.java:74)
  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:326)
  at 
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:342)
  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 

[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22061:
--
Description: 
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.

*UPDATE*

Binary tuple stores bigdecimal in compact form after IGNITE-21745.

This issue is about pre-allocation buffer for binary tuple.

Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size bigdecimal, including trailing zeros, causing the 
pre-allocated buffer to be significantly larger than required.



  was:
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.





> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size bigdecimal, including trailing zeros, causing the 
> pre-allocated buffer to be significantly larger than required.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22061:
--
Description: 
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.

*UPDATE*

Binary tuple stores bigdecimal in compact form after IGNITE-21745.

This issue is about pre-allocation buffer for binary tuple.

Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size of BigDecimal, including trailing zeros, causing the 
pre-allocated buffer to be significantly larger than required.



  was:
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.

*UPDATE*

Binary tuple stores bigdecimal in compact form after IGNITE-21745.

This issue is about pre-allocation buffer for binary tuple.

Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size bigdecimal, including trailing zeros, causing the 
pre-allocated buffer to be significantly larger than required.




> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the 
> pre-allocated buffer to be significantly larger than required.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22061:
--
Description: 
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.




  was:
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.

*UPDATE*

The 



> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


[ https://issues.apache.org/jira/browse/IGNITE-22061 ]


Pavel Pereslegin deleted comment on IGNITE-22061:
---

was (Author: xtern):
Looks like this issue is fixed in IGNITE-21745
The following test case now passes successfully.

{code:java}
int scale = Short.MAX_VALUE;
BigDecimal value = new BigDecimal("10").setScale(scale, RoundingMode.HALF_UP);
ByteBuffer bytes = new BinaryTupleBuilder(1).appendDecimal(value, 
scale).build();

assertEquals(5, bytes.limit());
{code}


> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-22061:
--
Description: 
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.

*UPDATE*

The 


  was:
BigDecimals that represent integer numbers can take up a lot of space, when 
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) - 
dc.stripTrailingZeros().setScale(0, 
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that 
does not store trailing zeros.



> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.
> *UPDATE*
> The 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros

2024-05-08 Thread Pavel Pereslegin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-22061:
-

Assignee: (was: Pavel Pereslegin)

> Use compact representation of BigDecimal with large scale for integers / 
> numbers with trailing zeros
> 
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when 
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024, 
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) - 
> dc.stripTrailingZeros().setScale(0, 
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form 
> that does not store trailing zeros.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-21950) Cover SQL T351(Bracketed SQL comments (/*...*/ comments)) feature by tests

2024-05-08 Thread Konstantin Orlov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-21950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Orlov reassigned IGNITE-21950:
-

Assignee: Konstantin Orlov

> Cover SQL T351(Bracketed SQL comments (/*...*/ comments)) feature by tests
> --
>
> Key: IGNITE-21950
> URL: https://issues.apache.org/jira/browse/IGNITE-21950
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Konstantin Orlov
>Priority: Major
>  Labels: ignite-3
>
> We don't have at all any tests for T351(Bracketed SQL comments (/*...*/ 
> comments)) SQL feature.
> Let's cover it and create tickets to fix them in case find any issues related 
> to the covered area



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (IGNITE-19091) Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. AssertError: Token must be greater than actual [token=4, actual=4]

2024-05-08 Thread Evgeny Stanilovsky (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-19091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgeny Stanilovsky resolved IGNITE-19091.
-
Fix Version/s: 3.0.0-beta2
   Resolution: Fixed

> Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. 
> AssertError: Token must be greater than actual [token=4, actual=4]
> -
>
> Key: IGNITE-19091
> URL: https://issues.apache.org/jira/browse/IGNITE-19091
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> After implementation of https://issues.apache.org/jira/browse/IGNITE-18225 
> ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart fails with an 
> error in code that processes table creation event: 
> .engine.schema.SqlSchemaManagerImpl.onTableCreated.
> AssertionError:
> {code:java}
> 2023-03-22 11:58:12:859 +0400 
> [WARNING][MessagingService-inbound-0][TableManager] Error occurred while 
> updating tables.
> java.util.concurrent.CompletionException: java.lang.AssertionError: Token 
> must be greater than actual [token=4, actual=4]
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.completeInternal(VersionedValue.java:323)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.lambda$completeOnRevision$4(VersionedValue.java:483)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$38(RaftGroupServiceImpl.java:525)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:363)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:328)
>   at 
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$3(DefaultMessagingService.java:306)
>   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: Token must be greater than actual 
> [token=4, actual=4]
>   at 
> org.apache.ignite.internal.causality.VersionedValue.checkToken(VersionedValue.java:580)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.update(VersionedValue.java:393)
>   at 
> org.apache.ignite.internal.sql.engine.schema.SqlSchemaManagerImpl.onTableCreated(SqlSchemaManagerImpl.java:218)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:583)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:575)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:108)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:129)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$36(TableManager.java:1183)
>   at 
> 

[jira] [Updated] (IGNITE-22186) Make JvmMetricSource confirm to the rules of IEP-116

2024-05-08 Thread Roman Puchkovskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-22186:
---
Description: 
[IEP-116|[https://cwiki.apache.org/confluence/display/IGNITE/IEP-116%3A+Metrics]]
 says that a metric source name may have structure delimited by period 
characters, but metric names cannot have such a structure.

JvmMetricSource behaves differently: its metrics have an hierarchicat structure.

This needs to be sorted out.

 

> Make JvmMetricSource confirm to the rules of IEP-116
> 
>
> Key: IGNITE-22186
> URL: https://issues.apache.org/jira/browse/IGNITE-22186
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> [IEP-116|[https://cwiki.apache.org/confluence/display/IGNITE/IEP-116%3A+Metrics]]
>  says that a metric source name may have structure delimited by period 
> characters, but metric names cannot have such a structure.
> JvmMetricSource behaves differently: its metrics have an hierarchicat 
> structure.
> This needs to be sorted out.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22186) Make JvmMetricSource confirm to the rules of IEP-116

2024-05-08 Thread Roman Puchkovskiy (Jira)
Roman Puchkovskiy created IGNITE-22186:
--

 Summary: Make JvmMetricSource confirm to the rules of IEP-116
 Key: IGNITE-22186
 URL: https://issues.apache.org/jira/browse/IGNITE-22186
 Project: Ignite
  Issue Type: Improvement
Reporter: Roman Puchkovskiy






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main

2024-05-08 Thread Mirza Aliev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirza Aliev reassigned IGNITE-22185:


Assignee: Mirza Aliev

> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
>  became flaky on the main 
> -
>
> Key: IGNITE-22185
> URL: https://issues.apache.org/jira/browse/IGNITE-22185
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> {{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
>  started to fail quite often recently.
> There are two possible errors in the logs: 
> {noformat}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
>   at 
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
>   at 
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
>   at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
>   at 
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
>   at 
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
>   at 
> org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
>   at 
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
> {noformat}
> or 
> {noformat}
> org.mockito.exceptions.misusing.UnfinishedStubbingException: 
> Unfinished stubbing detected here:
> -> at 
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
> {noformat}
> Need to investigate the problem



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main

2024-05-08 Thread Mirza Aliev (Jira)
Mirza Aliev created IGNITE-22185:


 Summary: 
DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
 became flaky on the main 
 Key: IGNITE-22185
 URL: https://issues.apache.org/jira/browse/IGNITE-22185
 Project: Ignite
  Issue Type: Bug
Reporter: Mirza Aliev


{{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
 started to fail quite often recently.
There are two possible errors in the logs: 


{noformat}
java.lang.AssertionError: java.util.concurrent.TimeoutException
  at 
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
  at 
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
  at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
  at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
  at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
  at 
org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
  at 
org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
{noformat}

or 

{noformat}
org.mockito.exceptions.misusing.UnfinishedStubbingException: 
Unfinished stubbing detected here:
-> at 
org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
{noformat}

Need to investigate the problem



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22184) ItClusterManagerTest#testJoinInvalidTag is flaky

2024-05-08 Thread Aleksandr Polovtsev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtsev updated IGNITE-22184:
-
Fix Version/s: 3.0.0-beta2

> ItClusterManagerTest#testJoinInvalidTag is flaky
> 
>
> Key: IGNITE-22184
> URL: https://issues.apache.org/jira/browse/IGNITE-22184
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: _Integration_Tests_Module_Cluster_Management_20239.log
>
>
> Looks like there's a race in this test: after the cluster is restarted, the 
> second node (which does not host the CMG) may be able to connect to the CMG 
> leader and send a join request after the CMG group is started, but before the 
> Cluster State is saved (which is done in a separate request).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22184) ItClusterManagerTest#testJoinInvalidTag is flaky

2024-05-08 Thread Aleksandr Polovtsev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtsev updated IGNITE-22184:
-
Attachment: _Integration_Tests_Module_Cluster_Management_20239.log

> ItClusterManagerTest#testJoinInvalidTag is flaky
> 
>
> Key: IGNITE-22184
> URL: https://issues.apache.org/jira/browse/IGNITE-22184
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Cluster_Management_20239.log
>
>
> Looks like there's a race in this test: after the cluster is restarted, the 
> second node (which does not host the CMG) may be able to connect to the CMG 
> leader and send a join request after the CMG group is started, but before the 
> Cluster State is saved (which is done in a separate request).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22184) ItClusterManagerTest#testJoinInvalidTag is flaky

2024-05-08 Thread Aleksandr Polovtsev (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtsev updated IGNITE-22184:
-
Description: Looks like there's a race in this test: after the cluster is 
restarted, the second node (which does not host the CMG) may be able to connect 
to the CMG leader and send a join request after the CMG group is started, but 
before the Cluster State is saved (which is done in a separate request).

> ItClusterManagerTest#testJoinInvalidTag is flaky
> 
>
> Key: IGNITE-22184
> URL: https://issues.apache.org/jira/browse/IGNITE-22184
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
>  Labels: ignite-3
>
> Looks like there's a race in this test: after the cluster is restarted, the 
> second node (which does not host the CMG) may be able to connect to the CMG 
> leader and send a join request after the CMG group is started, but before the 
> Cluster State is saved (which is done in a separate request).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (IGNITE-19091) Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. AssertError: Token must be greater than actual [token=4, actual=4]

2024-05-08 Thread Evgeny Stanilovsky (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-19091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844564#comment-17844564
 ] 

Evgeny Stanilovsky commented on IGNITE-19091:
-

[~mzhuravkov] can you review this trivial fix plz ?

> Sql. ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart failed. 
> AssertError: Token must be greater than actual [token=4, actual=4]
> -
>
> Key: IGNITE-19091
> URL: https://issues.apache.org/jira/browse/IGNITE-19091
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: calcite3-required, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After implementation of https://issues.apache.org/jira/browse/IGNITE-18225 
> ItIgniteNodeRestartTest::testQueryCorrectnessAfterNodeRestart fails with an 
> error in code that processes table creation event: 
> .engine.schema.SqlSchemaManagerImpl.onTableCreated.
> AssertionError:
> {code:java}
> 2023-03-22 11:58:12:859 +0400 
> [WARNING][MessagingService-inbound-0][TableManager] Error occurred while 
> updating tables.
> java.util.concurrent.CompletionException: java.lang.AssertionError: Token 
> must be greater than actual [token=4, actual=4]
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.completeInternal(VersionedValue.java:323)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.lambda$completeOnRevision$4(VersionedValue.java:483)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$sendWithRetry$38(RaftGroupServiceImpl.java:525)
>   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.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:363)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:328)
>   at 
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$3(DefaultMessagingService.java:306)
>   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: Token must be greater than actual 
> [token=4, actual=4]
>   at 
> org.apache.ignite.internal.causality.VersionedValue.checkToken(VersionedValue.java:580)
>   at 
> org.apache.ignite.internal.causality.VersionedValue.update(VersionedValue.java:393)
>   at 
> org.apache.ignite.internal.sql.engine.schema.SqlSchemaManagerImpl.onTableCreated(SqlSchemaManagerImpl.java:218)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:583)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor$TableCreatedListener.notify(SqlQueryProcessor.java:575)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:108)
>   at 
> org.apache.ignite.internal.manager.Producer.fireEvent(Producer.java:129)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$36(TableManager.java:1183)
>   at 
> 

[jira] [Created] (IGNITE-22184) ItClusterManagerTest#testJoinInvalidTag is flaky

2024-05-08 Thread Aleksandr Polovtsev (Jira)
Aleksandr Polovtsev created IGNITE-22184:


 Summary: ItClusterManagerTest#testJoinInvalidTag is flaky
 Key: IGNITE-22184
 URL: https://issues.apache.org/jira/browse/IGNITE-22184
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksandr Polovtsev
Assignee: Aleksandr Polovtsev






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (IGNITE-22101) Performance drop for thin client requests

2024-05-08 Thread Aleksey Plekhanov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-22101:
---
Ignite Flags:   (was: Release Notes Required)

> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: ise
> Fix For: 2.17
>
> Attachments: perf_drop.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional 
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)