[jira] [Updated] (IGNITE-19160) Improve message about sent partition file during snapshot restore

[Julia Bakulina (Jira)]

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

Julia Bakulina updated IGNITE-19160:

Description: 
Currently, message about partition is as below:
{quote}[2023-03-29T18:31:44,773][INFO 
][snapshot-runner-#863%node0%|#863%node0%][SnapshotSender] Partition file has 
been send [part=part-645.bin, pair={color:#ff}GroupPartitionId 
[grpId=1544803905, partId=645]{color}, length=45056]
{quote}
It does not tell us:
 # Receiver node id / address / consistent id.
 # Cache or cache group name which partition belongs to. Numerical group id is 
not convenient way to determine cache or cache group.

__

grpName is added to the message 'Partition file has been sent'

rmtAddr is added to the message 'File has been sent to remote node'

The output looks as follows now:
{code:java}
[2023-08-09T10:16:35,911][INFO 
][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][SnapshotSender]
 Partition file has been sent [part=part-811.bin, pair=GroupPartitionId 
[grpId=1544803905, partId=811], grpName=default, length=45056]{code}
{code:java}
[2023-08-09T10:16:35,907][INFO 
][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][GridIoManager]
 File has been sent to remote node [name=part-812.bin, uploadTime=0.0 sec, 
retries=0, transferred=45056, rmtId=9305e4a3-a325-4949-8421-3cd78150, 
rmtAddr=/127.0.0.1:47100]
{code}

  was:
Currently, message about partition is as below:
{quote}
[2023-03-29T18:31:44,773][INFO ][snapshot-runner-#863%node0%][SnapshotSender] 
Partition file has been send [part=part-645.bin, 
pair={color:red}GroupPartitionId [grpId=1544803905, partId=645]{color}, 
length=45056]
{quote}

It does not tell us: 
# Receiver node id / address / consistent id.
# Cache or cache group name which partition belongs to. Numerical group id is 
not convenient way to determine cache or cache group.




> Improve message about sent partition file during snapshot restore
> -
>
> Key: IGNITE-19160
> URL: https://issues.apache.org/jira/browse/IGNITE-19160
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: iep-43, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, message about partition is as below:
> {quote}[2023-03-29T18:31:44,773][INFO 
> ][snapshot-runner-#863%node0%|#863%node0%][SnapshotSender] Partition file has 
> been send [part=part-645.bin, pair={color:#ff}GroupPartitionId 
> [grpId=1544803905, partId=645]{color}, length=45056]
> {quote}
> It does not tell us:
>  # Receiver node id / address / consistent id.
>  # Cache or cache group name which partition belongs to. Numerical group id 
> is not convenient way to determine cache or cache group.
> __
> grpName is added to the message 'Partition file has been sent'
> rmtAddr is added to the message 'File has been sent to remote node'
> The output looks as follows now:
> {code:java}
> [2023-08-09T10:16:35,911][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][SnapshotSender]
>  Partition file has been sent [part=part-811.bin, pair=GroupPartitionId 
> [grpId=1544803905, partId=811], grpName=default, length=45056]{code}
> {code:java}
> [2023-08-09T10:16:35,907][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][GridIoManager]
>  File has been sent to remote node [name=part-812.bin, uploadTime=0.0 sec, 
> retries=0, transferred=45056, rmtId=9305e4a3-a325-4949-8421-3cd78150, 
> rmtAddr=/127.0.0.1:47100]
> {code}



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

[jira] [Updated] (IGNITE-19160) Improve message about sent partition file during snapshot restore

[Nikita Amelchev (Jira)]

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

Nikita Amelchev updated IGNITE-19160:
-
Release Note: Improved log message about sent partition file during 
snapshot restore  (was: Improved message about sent partition file during 
snapshot restore)

> Improve message about sent partition file during snapshot restore
> -
>
> Key: IGNITE-19160
> URL: https://issues.apache.org/jira/browse/IGNITE-19160
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: iep-43, ise
> Fix For: 2.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, message about partition is as below:
> {quote}[2023-03-29T18:31:44,773][INFO 
> ][snapshot-runner-#863%node0%|#863%node0%][SnapshotSender] Partition file has 
> been send [part=part-645.bin, pair={color:#ff}GroupPartitionId 
> [grpId=1544803905, partId=645]{color}, length=45056]
> {quote}
> It does not tell us:
>  # Receiver node id / address / consistent id.
>  # Cache or cache group name which partition belongs to. Numerical group id 
> is not convenient way to determine cache or cache group.
> __
> grpName is added to the message 'Partition file has been sent'
> rmtAddr is added to the message 'File has been sent to remote node'
> The output looks as follows now:
> {code:java}
> [2023-08-09T10:16:35,911][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][SnapshotSender]
>  Partition file has been sent [part=part-811.bin, pair=GroupPartitionId 
> [grpId=1544803905, partId=811], grpName=default, length=45056]{code}
> {code:java}
> [2023-08-09T10:16:35,907][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][GridIoManager]
>  File has been sent to remote node [name=part-812.bin, uploadTime=0.0 sec, 
> retries=0, transferred=45056, rmtId=9305e4a3-a325-4949-8421-3cd78150, 
> rmtAddr=/127.0.0.1:47100]
> {code}



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

[jira] [Updated] (IGNITE-19160) Improve message about sent partition file during snapshot restore

[Nikita Amelchev (Jira)]

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

Nikita Amelchev updated IGNITE-19160:
-
Fix Version/s: 2.16

> Improve message about sent partition file during snapshot restore
> -
>
> Key: IGNITE-19160
> URL: https://issues.apache.org/jira/browse/IGNITE-19160
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: iep-43, ise
> Fix For: 2.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, message about partition is as below:
> {quote}[2023-03-29T18:31:44,773][INFO 
> ][snapshot-runner-#863%node0%|#863%node0%][SnapshotSender] Partition file has 
> been send [part=part-645.bin, pair={color:#ff}GroupPartitionId 
> [grpId=1544803905, partId=645]{color}, length=45056]
> {quote}
> It does not tell us:
>  # Receiver node id / address / consistent id.
>  # Cache or cache group name which partition belongs to. Numerical group id 
> is not convenient way to determine cache or cache group.
> __
> grpName is added to the message 'Partition file has been sent'
> rmtAddr is added to the message 'File has been sent to remote node'
> The output looks as follows now:
> {code:java}
> [2023-08-09T10:16:35,911][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][SnapshotSender]
>  Partition file has been sent [part=part-811.bin, pair=GroupPartitionId 
> [grpId=1544803905, partId=811], grpName=default, length=45056]{code}
> {code:java}
> [2023-08-09T10:16:35,907][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][GridIoManager]
>  File has been sent to remote node [name=part-812.bin, uploadTime=0.0 sec, 
> retries=0, transferred=45056, rmtId=9305e4a3-a325-4949-8421-3cd78150, 
> rmtAddr=/127.0.0.1:47100]
> {code}



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

[jira] [Commented] (IGNITE-19160) Improve message about sent partition file during snapshot restore

[Julia Bakulina (Jira)]

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

Julia Bakulina commented on IGNITE-19160:
-

[~NSAmelchev], thank you for your review

> Improve message about sent partition file during snapshot restore
> -
>
> Key: IGNITE-19160
> URL: https://issues.apache.org/jira/browse/IGNITE-19160
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: iep-43, ise
> Fix For: 2.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, message about partition is as below:
> {quote}[2023-03-29T18:31:44,773][INFO 
> ][snapshot-runner-#863%node0%|#863%node0%][SnapshotSender] Partition file has 
> been send [part=part-645.bin, pair={color:#ff}GroupPartitionId 
> [grpId=1544803905, partId=645]{color}, length=45056]
> {quote}
> It does not tell us:
>  # Receiver node id / address / consistent id.
>  # Cache or cache group name which partition belongs to. Numerical group id 
> is not convenient way to determine cache or cache group.
> __
> grpName is added to the message 'Partition file has been sent'
> rmtAddr is added to the message 'File has been sent to remote node'
> The output looks as follows now:
> {code:java}
> [2023-08-09T10:16:35,911][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][SnapshotSender]
>  Partition file has been sent [part=part-811.bin, pair=GroupPartitionId 
> [grpId=1544803905, partId=811], grpName=default, length=45056]{code}
> {code:java}
> [2023-08-09T10:16:35,907][INFO 
> ][snapshot-runner-#798%snapshot.IgniteSnapshotRemoteRequestTest1%][GridIoManager]
>  File has been sent to remote node [name=part-812.bin, uploadTime=0.0 sec, 
> retries=0, transferred=45056, rmtId=9305e4a3-a325-4949-8421-3cd78150, 
> rmtAddr=/127.0.0.1:47100]
> {code}



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

[jira] [Updated] (IGNITE-19965) TableManager recovery

[Vyacheslav Koptilin (Jira)]

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

Vyacheslav Koptilin updated IGNITE-19965:
-
Epic Link: IGNITE-20166

> TableManager recovery
> -
>
> Key: IGNITE-19965
> URL: https://issues.apache.org/jira/browse/IGNITE-19965
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
>  Labels: ignite-3
>
> *Motivation*
> At the moment TableManager has the logic, which based on the two assumptions:
> - on the recovery we will receive the all needed configuration updates with 
> appropriate revision numbers
> - the same will be true for the all metastore updates
> But after the IGNITE-19778 both assumptions will be wrong.
> *Definition of done*
> - during the TableManager start all needed metastore data like rebalance keys 
> and stable assignments must be manually updated from metastore and 
> appropriate processing executed.
> - the logic which based on the configuration/metastore revision comparing (if 
> exists, but it look like it is migrated to DistributionZoneManager already) 
> must be fixed



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

[jira] [Resolved] (IGNITE-20032) NPE on a try to get a RAFT node's striped executor pool

[Vyacheslav Koptilin (Jira)]

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

Vyacheslav Koptilin resolved IGNITE-20032.
--
Resolution: Duplicate

This issue was fixed under IGNITE-20161

> NPE on a try to get a RAFT node's striped executor pool
> ---
>
> Key: IGNITE-20032
> URL: https://issues.apache.org/jira/browse/IGNITE-20032
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3
>
> Stopping the striped pool can happen earlier than the last RPC messafe is 
> processed.
> Just after the pool is stopped, its reference is reset to {{{}null{}}}:
> {code:java|title=org.apache.ignite.raft.jraft.core.NodeImpl#join|borderStyle=solid}
> if (opts.getStripedExecutor() != null && !opts.isSharedPools()) {
> opts.getStripedExecutor().shutdownGracefully();
> opts.setStripedExecutor(null);
>  }
> {code}
> {noformat}
> 2023-07-21 18:45:10:571 +0300 
> [ERROR][%int_tcpcat_5004%MessagingService-inbound--0][DefaultMessagingService]
>  onMessage() failed while processing InvokeRequestImpl [correlationId=30, 
> message=AppendEntriesRequestImpl [committedIndex=18558, 
> data=org.apache.ignite.raft.jraft.util.ByteString@1, entriesList=null, 
> groupId=unittest, peerId=int_tcpcat_5004, prevLogIndex=18559, prevLogTerm=1, 
> serverId=int_tcpcat_5007, term=2, timestampLong=110752845696729088]] from 
> int_tcpcat_5007
> java.lang.NullPointerException
>   at 
> org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor.getOrCreatePeerRequestContext(AppendEntriesRequestProcessor.java:351)
>   at 
> org.apache.ignite.raft.jraft.rpc.impl.core.AppendEntriesRequestProcessor$PeerExecutorSelector.select(AppendEntriesRequestProcessor.java:72)
>   at 
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.onReceived(IgniteRpcServer.java:182)
>   at 
> org.apache.ignite.network.DefaultMessagingService.onMessage(DefaultMessagingService.java:375)
>   at 
> org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:335)
>   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)
> {noformat}
> *Implementation notes*
> Something like busyLock can be introduced into this request processor. We 
> should check what error is sent in the request if the raft node is fully 
> stopped, and make the same behavior for cases when it is impossible to 
> acquire bufy lock (when the node is being stopped).



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

[jira] [Created] (IGNITE-20180) Fix flaky ItTablePersistenceTest#testSnapshot

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-20180:
--

 Summary: Fix flaky ItTablePersistenceTest#testSnapshot
 Key: IGNITE-20180
 URL: https://issues.apache.org/jira/browse/IGNITE-20180
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7421392?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildTestsSection=true&expandBuildProblemsSection=true



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

[jira] [Commented] (IGNITE-20056) .NET: Thin 3.0: Track observable timestamp

[Igor Sapego (Jira)]

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

Igor Sapego commented on IGNITE-20056:
--

Looks good to me.

> .NET: Thin 3.0: Track observable timestamp
> --
>
> Key: IGNITE-20056
> URL: https://issues.apache.org/jira/browse/IGNITE-20056
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Implement observable timestamp roundtrip in .NET client. See IGNITE-19888 for 
> more details.



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

[jira] [Commented] (IGNITE-19978) Java thin 3.0: Change Gradle dependencies from implementation to api

[Igor Sapego (Jira)]

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

Igor Sapego commented on IGNITE-19978:
--

Looks good to me.

> Java thin 3.0: Change Gradle dependencies from implementation to api
> 
>
> Key: IGNITE-19978
> URL: https://issues.apache.org/jira/browse/IGNITE-19978
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [build.gradle|https://github.com/apache/ignite-3/blob/797084781f5a0e34cb28e20ba694d772607e9642/modules/client/build.gradle]
>  for *ignite-client* module declares all dependencies as *implementation*. 
> However, for public API dependencies from *ignite-api* and *ignite-core* 
> modules we should change *implementation* to *api*, so that the users can add 
> a single *ignite-client* dependency to their Maven/Gradle project and avoid 
> adding transitive dependencies manually.



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

[jira] [Commented] (IGNITE-20152) PartitionAwarenessTest.startServer2 is flaky

[Igor Sapego (Jira)]

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

Igor Sapego commented on IGNITE-20152:
--

Looks good.

> PartitionAwarenessTest.startServer2 is flaky
> 
>
> Key: IGNITE-20152
> URL: https://issues.apache.org/jira/browse/IGNITE-20152
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunUnitTests/7409734?expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false
> {code}
> PartitionAwarenessTest STANDARD_ERROR
>   2023-08-03 16:28:06:595 +0300 [INFO][Test worker][ClientHandlerModule] 
> Thin client protocol started successfully [port=45259]
>   org.apache.ignite.client.PartitionAwarenessTest.initializationError
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:1e574be3-d6b5-4394-91a5-78aaf61991bd Cannot start thin client 
> connector endpoint. Port 45260 is in use.
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:1e574be3-d6b5-4394-91a5-78aaf61991bd Cannot start thin client 
> connector endpoint. Port 45260 is in use.
>   at 
> app//org.apache.ignite.client.handler.ClientHandlerModule.startEndpoint(ClientHandlerModule.java:273)
>   at 
> app//org.apache.ignite.client.handler.ClientHandlerModule.start(ClientHandlerModule.java:179)
>   at app//org.apache.ignite.client.TestServer.(TestServer.java:187)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.beforeAll(PartitionAwarenessTest.java:86)
>   at 
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>  Method)
>   at 
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>   at 
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>   at 
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptLifecycleMethod(TimeoutExtension.java:128)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptBeforeAllMethod(TimeoutExtension.java:70)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllMethods$13(ClassBasedTestDescriptor.java:411)
>   at 
> app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllMethods(ClassBasedTestDescriptor.java:409)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:215)
>   at 
> app//org.jun

[jira] [Commented] (IGNITE-19978) Java thin 3.0: Change Gradle dependencies from implementation to api

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn commented on IGNITE-19978:
-

Merged to main: ee06eb1bc00679c0fe2836d56a265c07dae8dd08

> Java thin 3.0: Change Gradle dependencies from implementation to api
> 
>
> Key: IGNITE-19978
> URL: https://issues.apache.org/jira/browse/IGNITE-19978
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [build.gradle|https://github.com/apache/ignite-3/blob/797084781f5a0e34cb28e20ba694d772607e9642/modules/client/build.gradle]
>  for *ignite-client* module declares all dependencies as *implementation*. 
> However, for public API dependencies from *ignite-api* and *ignite-core* 
> modules we should change *implementation* to *api*, so that the users can add 
> a single *ignite-client* dependency to their Maven/Gradle project and avoid 
> adding transitive dependencies manually.



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

[jira] [Comment Edited] (IGNITE-14865) Error handling in SQL module

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin edited comment on IGNITE-14865 at 8/9/23 11:29 AM:


Task for table/view exception handling: 
https://issues.apache.org/jira/browse/IGNITE-20181


was (Author: xtern):
Task for table/view exception handling already exists: 
https://issues.apache.org/jira/browse/IGNITE-14500

> Error handling in SQL module
> 
>
> Key: IGNITE-14865
> URL: https://issues.apache.org/jira/browse/IGNITE-14865
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> SQL is a part of pubic API and should throw only public exceptions. Let's 
> make sure that it will be true by adding conversation from internal exception 
> to public one
> on a border of the transition from the internal to the public part.
> The ticket should be based on result of IGNITE-19539 
> Also let's check KV view, Binary view, and fix it here or create separe 
> tickets in case it require many changes.



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

[jira] [Created] (IGNITE-20181) KV/Binary view public API should only throw public exceptions for the end user.

[Pavel Pereslegin (Jira)]

Pavel Pereslegin created IGNITE-20181:
-

 Summary: KV/Binary view public API should only throw public 
exceptions for the end user.
 Key: IGNITE-20181
 URL: https://issues.apache.org/jira/browse/IGNITE-20181
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Pereslegin


Revise the error handling of the KV/Binary view public API so that only a 
public exception is thrown to the end user.



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

[jira] [Comment Edited] (IGNITE-14865) Error handling in SQL module

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin edited comment on IGNITE-14865 at 8/9/23 11:31 AM:


Task for KV/Binary view exception handling: 
https://issues.apache.org/jira/browse/IGNITE-20181


was (Author: xtern):
Task for table/view exception handling: 
https://issues.apache.org/jira/browse/IGNITE-20181

> Error handling in SQL module
> 
>
> Key: IGNITE-14865
> URL: https://issues.apache.org/jira/browse/IGNITE-14865
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> SQL is a part of pubic API and should throw only public exceptions. Let's 
> make sure that it will be true by adding conversation from internal exception 
> to public one
> on a border of the transition from the internal to the public part.
> The ticket should be based on result of IGNITE-19539 
> Also let's check KV view, Binary view, and fix it here or create separe 
> tickets in case it require many changes.



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

[jira] [Resolved] (IGNITE-14500) Add table exceptions to public API.

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin resolved IGNITE-14500.
---
Resolution: Won't Fix

> Add table exceptions to public API.
> ---
>
> Key: IGNITE-14500
> URL: https://issues.apache.org/jira/browse/IGNITE-14500
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: iep-54, ignite-3
>
> * Let's introduce TableExceptions for various cases to public API
> * Replace any internal exception with the public one.
> * Use correct error codes defined in IGNITE-3690
> * Describe possibly thrown exceptions in javadoc to the public API methods.



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

[jira] [Commented] (IGNITE-20152) PartitionAwarenessTest.startServer2 is flaky

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn commented on IGNITE-20152:
-

Merged to main: 4dd47435791aa6010150f7e1b78df5267626cdb8

> PartitionAwarenessTest.startServer2 is flaky
> 
>
> Key: IGNITE-20152
> URL: https://issues.apache.org/jira/browse/IGNITE-20152
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunUnitTests/7409734?expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false
> {code}
> PartitionAwarenessTest STANDARD_ERROR
>   2023-08-03 16:28:06:595 +0300 [INFO][Test worker][ClientHandlerModule] 
> Thin client protocol started successfully [port=45259]
>   org.apache.ignite.client.PartitionAwarenessTest.initializationError
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:1e574be3-d6b5-4394-91a5-78aaf61991bd Cannot start thin client 
> connector endpoint. Port 45260 is in use.
> org.apache.ignite.lang.IgniteException: IGN-NETWORK-2 
> TraceId:1e574be3-d6b5-4394-91a5-78aaf61991bd Cannot start thin client 
> connector endpoint. Port 45260 is in use.
>   at 
> app//org.apache.ignite.client.handler.ClientHandlerModule.startEndpoint(ClientHandlerModule.java:273)
>   at 
> app//org.apache.ignite.client.handler.ClientHandlerModule.start(ClientHandlerModule.java:179)
>   at app//org.apache.ignite.client.TestServer.(TestServer.java:187)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.beforeAll(PartitionAwarenessTest.java:86)
>   at 
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>  Method)
>   at 
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>   at 
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>   at 
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptLifecycleMethod(TimeoutExtension.java:128)
>   at 
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptBeforeAllMethod(TimeoutExtension.java:70)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
>   at 
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>   at 
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllMethods$13(ClassBasedTestDescriptor.java:411)
>   at 
> app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllMethods(ClassBasedTestDescriptor.java:409)
>   at 
> app//org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBased

[jira] [Assigned] (IGNITE-19953) Ignite 3 CLI: --verbose twice does not work

[Ivan Zlenko (Jira)]

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

Ivan Zlenko reassigned IGNITE-19953:


Assignee: Ivan Zlenko  (was: Aleksandr)

> Ignite 3 CLI: --verbose twice does not work
> ---
>
> Key: IGNITE-19953
> URL: https://issues.apache.org/jira/browse/IGNITE-19953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr
>Assignee: Ivan Zlenko
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
> Attachments: Screenshot 2023-07-11 at 16.10.43.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Just call any command with --verbose twice in REPL mode. The first one prints 
> HTTP trace, the second one no.



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

[jira] [Updated] (IGNITE-20133) Compute hashes for integral/decimal columns in a stable way

[Sergey Chugunov (Jira)]

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

Sergey Chugunov updated IGNITE-20133:
-
Priority: Minor  (was: Major)

> Compute hashes for integral/decimal columns in a stable way
> ---
>
> Key: IGNITE-20133
> URL: https://issues.apache.org/jira/browse/IGNITE-20133
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The idea is to make hash computation for integral and decimal types satisfy 
> the following property: if a column type is changed from an integral to a 
> decimal type, the hashes for values that are already stored remain the same.
> This will allow us to permit chaning type (integral -> decimal and decimal -> 
> longer decimal) of a column that is included in a HASH index.
> A hash that has this property is the following function: 
> hash(val.toString(TRIM_TRAILING_ZEROS)). For instance, for 1 it will be 
> hash("1"), for 1.000 it will also be hash("1"), but for 1.23 it will give 
> hash("1.23").



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

[jira] [Commented] (IGNITE-20056) .NET: Thin 3.0: Track observable timestamp

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn commented on IGNITE-20056:
-

Merged to main: e490bfe781dd0cdc57660e841307ecd8a6ffec20

> .NET: Thin 3.0: Track observable timestamp
> --
>
> Key: IGNITE-20056
> URL: https://issues.apache.org/jira/browse/IGNITE-20056
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Implement observable timestamp roundtrip in .NET client. See IGNITE-19888 for 
> more details.



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

[jira] [Created] (IGNITE-20182) Sql. ExchangeExecutionTest#racesBetweenRewindAndBatchesFromPreviousRequest rarely failed

[Evgeny Stanilovsky (Jira)]

Evgeny Stanilovsky created IGNITE-20182:
---

 Summary: Sql. 
ExchangeExecutionTest#racesBetweenRewindAndBatchesFromPreviousRequest rarely 
failed
 Key: IGNITE-20182
 URL: https://issues.apache.org/jira/browse/IGNITE-20182
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
 Attachments: image-2023-08-09-16-09-52-058.png

run until failure:
ExchangeExecutionTest#racesBetweenRewindAndBatchesFromPreviousRequest
 !image-2023-08-09-16-09-52-058.png! 



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

[jira] [Updated] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20183:

Priority: Critical  (was: Major)

> Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
> ---
>
> Key: IGNITE-20183
> URL: https://issues.apache.org/jira/browse/IGNITE-20183
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>




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

[jira] [Created] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-20183:
---

 Summary: Java thin 3.0: testNonNullTxDisablesPartitionAwareness is 
flaky
 Key: IGNITE-20183
 URL: https://issues.apache.org/jira/browse/IGNITE-20183
 Project: Ignite
  Issue Type: Improvement
  Components: thin client
Affects Versions: 3.0.0-beta1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 3.0.0-beta2






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

[jira] [Updated] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20183:

Description: 
{code}
org.opentest4j.AssertionFailedError: Operation get was not executed on expected 
node ==> expected:  but was: 
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
  at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
  at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
  at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
{code}

> Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
> ---
>
> Key: IGNITE-20183
> URL: https://issues.apache.org/jira/browse/IGNITE-20183
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> org.opentest4j.AssertionFailedError: Operation get was not executed on 
> expected node ==> expected:  but was: 
>   at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>   at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>   at 
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
>   at 
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>   at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
> {code}



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

[jira] [Updated] (IGNITE-20183) Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20183:

Description: 
https://ci.ignite.apache.org/test/-5961865609456060252?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true

{code}
org.opentest4j.AssertionFailedError: Operation get was not executed on expected 
node ==> expected:  but was: 
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
  at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
  at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
  at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
{code}

Seems to be caused by IGNITE-20152 fix - random port causes random node 
ordering.

  was:
{code}
org.opentest4j.AssertionFailedError: Operation get was not executed on expected 
node ==> expected:  but was: 
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
  at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
  at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
  at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
  at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
  at 
app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
{code}


> Java thin 3.0: testNonNullTxDisablesPartitionAwareness is flaky
> ---
>
> Key: IGNITE-20183
> URL: https://issues.apache.org/jira/browse/IGNITE-20183
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/test/-5961865609456060252?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> {code}
> org.opentest4j.AssertionFailedError: Operation get was not executed on 
> expected node ==> expected:  but was: 
>   at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>   at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>   at 
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
>   at 
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>   at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1153)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.assertOpOnNode(PartitionAwarenessTest.java:591)
>   at 
> app//org.apache.ignite.client.PartitionAwarenessTest.testNonNullTxDisablesPartitionAwareness(PartitionAwarenessTest.java:157)
> {code}
> Seems to be caused by IGNITE-20152 fix - random port causes random node 
> ordering.



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

[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue

[Alexandr Shapkin (Jira)]

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

Alexandr Shapkin updated IGNITE-20139:
--
Description: 
We tried to use machine learning capabilities, and discovered a bug in 
implementation of Random Forest. When comparing Ignite's output with python 
prototype (scikit-learn lib), we noticed that Ignite's predictions have much 
lower accuracy despite using the same data set and model parameters. 

Further investigation showed that Ignite generates decision trees that kinda 
"loop". The tree starts checking the same condition over and over until it 
reaches the maximum tree depth.

I've attached a standalone reproducer which uses a small excerpt of our data 
set. 

It loads data from the csv file, then performs the training of the model for 
just 1 tree. Then the reproducer finds one of the looping branches and prints 
it. You will see that every single node in the branch uses the same feature, 
value and has then same calculated impurity. 

On my machine the code reproduces this issue 100% of time.

I've also attached an example of the tree generated by python's scikit-learn on 
the same data set with the same parameters. In python the tree usually doesn't 
get deeper than 20 nodes.

  was:
We tried to use GridGain's machine learning capabilities, and discovered a bug 
in GG's implementation of Random Forest. When comparing GG's output with python 
prototype (scikit-learn lib), we noticed that GG's predictions have much lower 
accuracy despite using the same data set and model parameters. 

Further investigation showed that GridGain generates decision trees that kinda 
"loop". The tree starts checking the same condition over and over until it 
reaches the maximum tree depth.

I've attached a standalone reproducer which uses a small excerpt of our data 
set. 

It loads data from the csv file, then performs the training of the model for 
just 1 tree. Then the reproducer finds one of the looping branches and prints 
it. You will see that every single node in the branch uses the same feature, 
value and has then same calculated impurity. 

On my machine the code reproduces this issue 100% of time.

I've also attached an example of the tree generated by python's scikit-learn on 
the same data set with the same parameters. In python the tree usually doesn't 
get deeper than 20 nodes.


> RandomForestClassifierTrainer accuracy issue
> 
>
> Key: IGNITE-20139
> URL: https://issues.apache.org/jira/browse/IGNITE-20139
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.15
>Reporter: Alexandr Shapkin
>Assignee: Igor Belyakov
>Priority: Major
> Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip
>
>
> We tried to use machine learning capabilities, and discovered a bug in 
> implementation of Random Forest. When comparing Ignite's output with python 
> prototype (scikit-learn lib), we noticed that Ignite's predictions have much 
> lower accuracy despite using the same data set and model parameters. 
> Further investigation showed that Ignite generates decision trees that kinda 
> "loop". The tree starts checking the same condition over and over until it 
> reaches the maximum tree depth.
> I've attached a standalone reproducer which uses a small excerpt of our data 
> set. 
> It loads data from the csv file, then performs the training of the model for 
> just 1 tree. Then the reproducer finds one of the looping branches and prints 
> it. You will see that every single node in the branch uses the same feature, 
> value and has then same calculated impurity. 
> On my machine the code reproduces this issue 100% of time.
> I've also attached an example of the tree generated by python's scikit-learn 
> on the same data set with the same parameters. In python the tree usually 
> doesn't get deeper than 20 nodes.



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

[jira] [Created] (IGNITE-20184) Move dataStorage configuration from zone to table configuration config

[Kirill Gusakov (Jira)]

Kirill Gusakov created IGNITE-20184:
---

 Summary:  Move dataStorage configuration from zone to table 
configuration config
 Key: IGNITE-20184
 URL: https://issues.apache.org/jira/browse/IGNITE-20184
 Project: Ignite
  Issue Type: Task
Reporter: Kirill Gusakov


After IGNITE-19002 we decided to move the dataStorage configuration back, 
because the clarification in the design of table-zone relations. Appropriate 
tests for table dataStorage configuration should be restored too



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

[jira] [Updated] (IGNITE-19368) Fix ignite-cdc-ext assembly

[Ilya Shishkov (Jira)]

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

Ilya Shishkov updated IGNITE-19368:
---
Release Note:   (was: Merged to master. Thank you for contribution!)

> Fix ignite-cdc-ext assembly
> ---
>
> Key: IGNITE-19368
> URL: https://issues.apache.org/jira/browse/IGNITE-19368
> Project: Ignite
>  Issue Type: Bug
>  Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
>  Labels: IEP-59, ise
>
> Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the 
> assembled zip file. It have been happened after IGNITE-19237. Assembly can be 
> fixed in the same way as it was done in performance statistics module [1].
> # 
> https://github.com/apache/ignite-extensions/blob/b7dd81fb7d9c41f35afb7dc10d060f685dfeac6f/modules/performance-statistics-ext/pom.xml#L152



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

[jira] [Updated] (IGNITE-19829) ignite-cdc-ext: move jackson-databind dependency to test scope

[Ilya Shishkov (Jira)]

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

Ilya Shishkov updated IGNITE-19829:
---
Description: 
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency has been in test scope, so we can move Jackson 
dependency to test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can se that {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly.

  was:
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency is test scope, so we can move Jackson dependency to 
test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can se that {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly.


> ignite-cdc-ext: move jackson-databind dependency to test scope
> --
>
> Key: IGNITE-19829
> URL: https://issues.apache.org/jira/browse/IGNITE-19829
> Project: Ignite
>  Issue Type: Task
>  Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
>  Labels: IEP-59, ise
>
> In IGNITE-18318 Jackson dependency have been added with default scope, 
> because it is necessary for {{kafka_2.12}} dependency. But, after 
> IGNITE-18179 {{kafka_2.12}} dependency has been in test scope, so we can move 
> Jackson dependency to test scope too.
> Below there is part of dependency tree which had been present before explicit 
> exclusion of jackson dependency in IGNITE-18318:
> {noformat}
> +- org.apache.kafka:kafka_2.12:jar:2.7.0:test
> |  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
> |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
> {noformat}
> As we can se that {{jackson-databind}} is used only in test scope, so it can 
> be safely deleted from assembly.



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

[jira] [Updated] (IGNITE-19877) Sql. Erroneous cast possibility Custom object to Numeric.

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky updated IGNITE-19877:

Fix Version/s: 3.0.0-beta2

> Sql. Erroneous cast possibility Custom object to Numeric.
> -
>
> Key: IGNITE-19877
> URL: https://issues.apache.org/jira/browse/IGNITE-19877
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> {code:java}
> @Test
> public void test0() {
> String query = format("SELECT CAST(? AS DECIMAL(5, 1))");
> assertQuery(query).withParams(LocalTime.now()).returns(2).ok();
> }
> {code}
> Throws Numeric overflow exception, seems this is incorrect behavior.
> Seems scope of this issue is to check casting of: 
> 1. not supported objects 
> 2. IgniteCustomType
> full casting matrix need to be fixed in scope of [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-20069



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

[jira] [Created] (IGNITE-20185) Sql. Fix missed casting rules after IGNITE-19877

[Evgeny Stanilovsky (Jira)]

Evgeny Stanilovsky created IGNITE-20185:
---

 Summary: Sql. Fix missed casting rules after IGNITE-19877
 Key: IGNITE-20185
 URL: https://issues.apache.org/jira/browse/IGNITE-20185
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky


YM, DT yearmonth and daytime intervals can be casted into exact numeric and the 
opposite is correct too.



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

[jira] [Assigned] (IGNITE-20185) Sql. Fix missed casting rules after IGNITE-19877

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky reassigned IGNITE-20185:
---

Assignee: Evgeny Stanilovsky

> Sql. Fix missed casting rules after IGNITE-19877
> 
>
> Key: IGNITE-20185
> URL: https://issues.apache.org/jira/browse/IGNITE-20185
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> YM, DT yearmonth and daytime intervals can be casted into exact numeric and 
> the opposite is correct too.



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

[jira] [Created] (IGNITE-20186) [Ignite Website] Add Upcoming Events

[Evgenia (Jira)]

Evgenia created IGNITE-20186:


 Summary: [Ignite Website] Add Upcoming Events
 Key: IGNITE-20186
 URL: https://issues.apache.org/jira/browse/IGNITE-20186
 Project: Ignite
  Issue Type: Task
  Components: website
Reporter: Evgenia


Update [Apache Ignite Events - Meetups, Summit, 
Conference|https://ignite.apache.org/events.html#upcoming] page with upcoming 
talks.

 

1) Event: Community over code, Halifax, Canada, October 9

Talk Title - Enhancing Apache Ignite 3.0 with the Power of Open-Source

Speaker - Stanislav Lukyanov

Link - [Schedule List – Community Over 
Code|https://communityovercode.org/schedule-list/#BDC006]

2)  Event: Community over code, Halifax, Canada, October 8

Scalable Distributed Computing with Groovy Using Apache Ignite

Jeremy Meyer

[Schedule List – Community Over 
Code|https://communityovercode.org/schedule-list/#GR008]

3) Event: Community over code, Halifax, Canada, October 8 

Whiskey Clustering with Apache Groovy and Apache Ignite

Paul King

[Schedule List – Community Over 
Code|https://communityovercode.org/schedule-list/#GR007]



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

[jira] [Updated] (IGNITE-20053) Empty data nodes are returned by data nodes engine

[Alexander Lapin (Jira)]

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

Alexander Lapin updated IGNITE-20053:
-
Description: 
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

The reason for empty data nodes assertion is race between join completion and 
thus firing logical topology updates and DZM start. Literally, it's required to 
put 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

However, that's not the whole story. We also faced 
{code:java}
Unable to initialize the cluster: null{code}
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}

  was:
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

The reason for empty data nodes assertion is race between join completion and 
thus firing logical topology updates and DZM start. Literally, it's required to 
put 

 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before

 

 
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

 

However, that's not the whole story. We also faced 
Unable to initialize the cluster: null
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}


> Empty data nodes are returned by data nodes engine
> --
>
> Key: IGNITE-20053
> URL: https://issues.apache.org/jira/browse/IGNITE-20053
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
>  Labels: ignite-3
>
> There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY 
> and it is refreshed by topology listener on topology events and stores 
> logical topology. If the value stored by this key is null, then empty data 
> nodes are returned from data nodes engine on data nodes calculation for a 
> distribution zone. As a result, empty assignments are calculated for 
> partitions, which leads to exception described in IGNITE-19466.
> Some integration tests, for example, ItRebalanceDistributedTest are flaky 
> because of possible problems with value of 
> DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by 
> data nodes engine.
> Actually, the empty data nodes collection is a wrong result for this case 
> because the current logical topology is not empty.
> h3. UPD #1
> The reason for

[jira] [Updated] (IGNITE-20053) Empty data nodes are returned by data nodes engine

[Alexander Lapin (Jira)]

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

Alexander Lapin updated IGNITE-20053:
-
Description: 
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

The reason for empty data nodes assertion is race between join completion and 
thus firing logical topology updates and DZM start. Literally, it's required to 
put 

 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before

 

 
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

 

However, that's not the whole story. We also faced 
Unable to initialize the cluster: null
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}

  was:
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.


> Empty data nodes are returned by data nodes engine
> --
>
> Key: IGNITE-20053
> URL: https://issues.apache.org/jira/browse/IGNITE-20053
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
>  Labels: ignite-3
>
> There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY 
> and it is refreshed by topology listener on topology events and stores 
> logical topology. If the value stored by this key is null, then empty data 
> nodes are returned from data nodes engine on data nodes calculation for a 
> distribution zone. As a result, empty assignments are calculated for 
> partitions, which leads to exception described in IGNITE-19466.
> Some integration tests, for example, ItRebalanceDistributedTest are flaky 
> because of possible problems with value of 
> DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by 
> data nodes engine.
> Actually, the empty data nodes collection is a wrong result for this case 
> because the current logical topology is not empty.
> h3. UPD #1
> The reason for empty data nodes assertion is race between join completion and 
> thus firing logical topology updates and DZM start. Literally, it's required 
> to put 
>  
> {code:java}
> nodes.stream().forEach(Node::waitWatches); {code}
> before
>  
>  
> {code:java}
> assertThat(
> allOf(nodes.get(0).cmgManager.onJoinReady(), 
> nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
> willCompleteSuccessfully()
> ); {code}
> in 
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.
>  
>  
> However, that's not the whole story. We also faced 
> Unable to initialize the cluster: null
> because cmg init failed with TimeoutException because we start CMGManager 
> asynchronously, which is incorrect. So if we move cmgManager to 
> firstComponents that will solve the issue.
> {code:java}
> List firstComponents = List.of(
> vaultManager,
> nodeCfgMgr,
> clusterService,
> raftManager,
>

[jira] [Updated] (IGNITE-20053) Empty data nodes are returned by data nodes engine

[Alexander Lapin (Jira)]

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

Alexander Lapin updated IGNITE-20053:
-
Description: 
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

*1.* The reason for empty data nodes assertion is race between join completion 
and thus firing logical topology updates and DZM start. Literally, it's 
required to put 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

*2.* However, that's not the whole story. We also faced 
{code:java}
Unable to initialize the cluster: null{code}
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}
 

*3.* Still it's not the whole story. testTwoQueuedRebalances failed because we 
didn't retrieved an expected stable assignments after table creation
{code:java}
await(nodes.get(0).tableManager.createTableAsync(
"TBL1",
ZONE_1_NAME,
tblChanger -> SchemaConfigurationConverter.convert(schTbl1, tblChanger)
));

assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
The reason for that is that assignments calculation is an async process, so 
there are no guarantees that we will retrieve proper assignments right after 
table creation completes. So we might substitute
{code:java}
assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
with
{code:java}
assertTrue(waitForCondition(() -> getPartitionClusterNodes(0, 0).size() == 1, 
1_000));{code}

  was:
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

The reason for empty data nodes assertion is race between join completion and 
thus firing logical topology updates and DZM start. Literally, it's required to 
put 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

However, that's not the whole story. We also faced 
{code:java}
Unable to initialize the cluster: null{code}
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}


> Empty data nodes are returned by data nodes engine
> --
>
> Key: IGNITE-20053
> URL: https://issues.apache.org/jira/browse/IGNITE-20053
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
>  Labels: ignite-3
>
> There is a meta stora

[jira] [Created] (IGNITE-20187) Catch-up rebalance on node restart: assignments keys

[Alexander Lapin (Jira)]

Alexander Lapin created IGNITE-20187:


 Summary: Catch-up rebalance on node restart: assignments keys
 Key: IGNITE-20187
 URL: https://issues.apache.org/jira/browse/IGNITE-20187
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexander Lapin






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

[jira] [Updated] (IGNITE-20053) Empty data nodes are returned by data nodes engine

[Alexander Lapin (Jira)]

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

Alexander Lapin updated IGNITE-20053:
-
Description: 
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

*1.* The reason for empty data nodes assertion is race between join completion 
and thus firing logical topology updates and DZM start. Literally, it's 
required to put 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

*2.* However, that's not the whole story. We also faced 
{code:java}
Unable to initialize the cluster: null{code}
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}
 

*3.* Still it's not the whole story. testTwoQueuedRebalances failed because we 
didn't retrieved an expected stable assignments after table creation
{code:java}
await(nodes.get(0).tableManager.createTableAsync(
"TBL1",
ZONE_1_NAME,
tblChanger -> SchemaConfigurationConverter.convert(schTbl1, tblChanger)
));

assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
The reason for that is that assignments calculation is an async process, so 
there are no guarantees that we will retrieve proper assignments right after 
table creation completes. So we might substitute
{code:java}
assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
with
{code:java}
assertTrue(waitForCondition(() -> getPartitionClusterNodes(0, 0).size() == 1, 
10_000));{code}
Please pay attention that there are multiple places where we retrieve 
assignments and expect them to be ready.

  was:
There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and 
it is refreshed by topology listener on topology events and stores logical 
topology. If the value stored by this key is null, then empty data nodes are 
returned from data nodes engine on data nodes calculation for a distribution 
zone. As a result, empty assignments are calculated for partitions, which leads 
to exception described in IGNITE-19466.

Some integration tests, for example, ItRebalanceDistributedTest are flaky 
because of possible problems with value of 
DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by data 
nodes engine.

Actually, the empty data nodes collection is a wrong result for this case 
because the current logical topology is not empty.
h3. UPD #1

*1.* The reason for empty data nodes assertion is race between join completion 
and thus firing logical topology updates and DZM start. Literally, it's 
required to put 
{code:java}
nodes.stream().forEach(Node::waitWatches); {code}
before
{code:java}
assertThat(
allOf(nodes.get(0).cmgManager.onJoinReady(), 
nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
willCompleteSuccessfully()
); {code}
in 
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.

 

*2.* However, that's not the whole story. We also faced 
{code:java}
Unable to initialize the cluster: null{code}
because cmg init failed with TimeoutException because we start CMGManager 
asynchronously, which is incorrect. So if we move cmgManager to firstComponents 
that will solve the issue.
{code:java}
List firstComponents = List.of(
vaultManager,
nodeCfgMgr,
clusterService,
raftManager,
cmgManager
); {code}
 

*3.* Still it's not the whole story. testTwoQueuedRebalances failed because we 
didn't retrieved an expected stable assignments after table creation
{code:java}
await(nodes.get(0).tableManager.createTableAsync(
"TBL1",
ZONE_1_NAME,
tblChanger -> SchemaConfigurationConverter.convert(sc

[jira] [Assigned] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin reassigned IGNITE-20035:
-

Assignee: Pavel Pereslegin

> IndexOutOfBoundsException when statement.SetMaxRows is set
> --
>
> Key: IGNITE-20035
> URL: https://issues.apache.org/jira/browse/IGNITE-20035
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> If setMaxRows > count(*) - query fail with IndexOutOfBound exception.
> Reproducer:
>  
> {noformat}
> try (Connection connection = connect(); Statement statement = 
> connection.createStatement()) {
> JdbcSteps steps = new JdbcSteps(statement);
> steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name 
> VARCHAR)", "Creating a table with two columns.");
> steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1, 
> 'John')", "Inserting a single record");
> statement.setMaxRows(25);
> ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all 
> the records from the table");
> while (res.next()) {
> log.info("{}, {}", res.getInt(1), res.getString(2));
> assertEquals(1, res.getInt(1));
> assertEquals("John", res.getString(2));
> }
> }{noformat}
> Returns:
>  
>  
> {noformat}
> Exception while executing query [query=SELECT * FROM Person]. Error 
> message:toIndex = 25
> java.sql.SQLException: Exception while executing query [query=SELECT * FROM 
> Person]. Error message:toIndex = 25
>     at 
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
>     at 
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149)
>     at 
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108)
>     at 
> org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50)
>     at 
> org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>     at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>     at 
> org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>     at 
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>     at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>     at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
>     at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>     at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>     at 

[jira] [Updated] (IGNITE-19829) ignite-cdc-ext: move jackson-databind dependency to test scope

[Ilya Shishkov (Jira)]

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

Ilya Shishkov updated IGNITE-19829:
---
Description: 
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency is in test scope, so we can move Jackson dependency 
to test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can se that {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly.

  was:
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency has been in test scope, so we can move Jackson 
dependency to test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can se that {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly.


> ignite-cdc-ext: move jackson-databind dependency to test scope
> --
>
> Key: IGNITE-19829
> URL: https://issues.apache.org/jira/browse/IGNITE-19829
> Project: Ignite
>  Issue Type: Task
>  Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
>  Labels: IEP-59, ise
>
> In IGNITE-18318 Jackson dependency have been added with default scope, 
> because it is necessary for {{kafka_2.12}} dependency. But, after 
> IGNITE-18179 {{kafka_2.12}} dependency is in test scope, so we can move 
> Jackson dependency to test scope too.
> Below there is part of dependency tree which had been present before explicit 
> exclusion of jackson dependency in IGNITE-18318:
> {noformat}
> +- org.apache.kafka:kafka_2.12:jar:2.7.0:test
> |  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
> |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
> {noformat}
> As we can se that {{jackson-databind}} is used only in test scope, so it can 
> be safely deleted from assembly.



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

[jira] [Updated] (IGNITE-19829) ignite-cdc-ext: move jackson-databind dependency to test scope

[Ilya Shishkov (Jira)]

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

Ilya Shishkov updated IGNITE-19829:
---
Description: 
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency is in test scope, so we can move Jackson dependency 
to test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can see, {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly, i.e. moved to test scope.

  was:
In IGNITE-18318 Jackson dependency have been added with default scope, because 
it is necessary for {{kafka_2.12}} dependency. But, after IGNITE-18179 
{{kafka_2.12}} dependency is in test scope, so we can move Jackson dependency 
to test scope too.

Below there is part of dependency tree which had been present before explicit 
exclusion of jackson dependency in IGNITE-18318:
{noformat}
+- org.apache.kafka:kafka_2.12:jar:2.7.0:test
|  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
|  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
{noformat}

As we can se that {{jackson-databind}} is used only in test scope, so it can be 
safely deleted from assembly.


> ignite-cdc-ext: move jackson-databind dependency to test scope
> --
>
> Key: IGNITE-19829
> URL: https://issues.apache.org/jira/browse/IGNITE-19829
> Project: Ignite
>  Issue Type: Task
>  Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
>  Labels: IEP-59, ise
>
> In IGNITE-18318 Jackson dependency have been added with default scope, 
> because it is necessary for {{kafka_2.12}} dependency. But, after 
> IGNITE-18179 {{kafka_2.12}} dependency is in test scope, so we can move 
> Jackson dependency to test scope too.
> Below there is part of dependency tree which had been present before explicit 
> exclusion of jackson dependency in IGNITE-18318:
> {noformat}
> +- org.apache.kafka:kafka_2.12:jar:2.7.0:test
> |  +- org.apache.kafka:kafka-raft:jar:2.7.0:test
> |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.10.5.1:test
> {noformat}
> As we can see, {{jackson-databind}} is used only in test scope, so it can be 
> safely deleted from assembly, i.e. moved to test scope.



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

[jira] [Created] (IGNITE-20188) Add improvements to the catalog associated with the DistributionZone #2

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-20188:


 Summary: Add improvements to the catalog associated with the 
DistributionZone #2
 Key: IGNITE-20188
 URL: https://issues.apache.org/jira/browse/IGNITE-20188
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 3.0.0-beta2


During the implementation of IGNITE-20114, the following necessary improvements 
were discovered:
* Getting a zone from a catalog by ID and catalog version;
* Getting zones from a catalog by catalog version;
* Default zone has no data storage;
* If possible, improve the method of adding a catalog event listener, make it 
more generically;
* Create zone change listener in catalog and its fields.



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

[jira] [Created] (IGNITE-20189) Prepare existing tests for the distributed zone to switch to the catalog #2

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-20189:


 Summary: Prepare existing tests for the distributed zone to switch 
to the catalog #2
 Key: IGNITE-20189
 URL: https://issues.apache.org/jira/browse/IGNITE-20189
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 3.0.0-beta2


During IGNITE-20114, it was discovered that the tests used zone IDs as 
constants, which is not the right solution, and also complicates the switch of 
these tests to the catalog.

We need to take the zone ID from the configuration.



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

[jira] [Created] (IGNITE-20190) Sql. Casting literals into numeric types have different rounding mode from dynamic params

[Evgeny Stanilovsky (Jira)]

Evgeny Stanilovsky created IGNITE-20190:
---

 Summary: Sql. Casting literals into numeric types have different 
rounding mode from dynamic params
 Key: IGNITE-20190
 URL: https://issues.apache.org/jira/browse/IGNITE-20190
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky


Check:
ItDataTypesTest 

{noformat}
arguments(CaseStatus.SKIP, decimalType(5, 2), new BigDecimal("100.16"), 
decimalType(4, 1), bigDecimalVal("100.2")),
{noformat}

SELECT CAST(100.16::DECIMAL(5, 2) AS DECIMAL(4, 1)) returns 100.2 when called 
with dynamic parameters and truncated = 100.1 when called as literal



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

[jira] (IGNITE-19947) Sql. Fix CAST(n AS DECIMAL(precision, scale) behaviour for scale > precision.

[Evgeny Stanilovsky (Jira)]

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


Evgeny Stanilovsky deleted comment on IGNITE-19947:
-

was (Author: zstan):
let`s fill appropriate issue into Calcite after and fix it too.

> Sql. Fix CAST(n AS DECIMAL(precision, scale) behaviour for scale > precision.
> -
>
> Key: IGNITE-19947
> URL: https://issues.apache.org/jira/browse/IGNITE-19947
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> CAST(n AS DECIMAL(p, s) always returns `numeric field overflow` error when s 
> > p which is not correct, in such case we should also check `n`.
> Example:
> {code:java}
> SELECT CAST (? AS DECIMAL(1,4)) ? = 0.0001
> # PG returns 0.0001
> # Ignite 3 returns numeric field overflow
> {code}
> Query with a literal works because calcite performs constant folding and 
> removes a CAST call:
> {code:java}
> SELECT CAST (0.0001 AS DECIMAL(1,4))
> # Plan
> IgniteValues(tuples=[[{ 0.0001 }]]), id = 8
> {code}



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

[jira] [Updated] (IGNITE-20190) Sql. Casting literals into numeric types have different rounding mode from dynamic params

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky updated IGNITE-20190:

Description: 
Check:
ItDataTypesTest 

{noformat}
arguments(CaseStatus.SKIP, decimalType(5, 2), new BigDecimal("100.16"), 
decimalType(4, 1), bigDecimalVal("100.2")),
{noformat}

SELECT CAST(100.16::DECIMAL(5, 2) AS DECIMAL(4, 1)) returns 100.2 when called 
with dynamic parameters and truncated = 100.1 when called as literal

check, pg mysql and ora are rounding, not truncated i.e:
SELECT CAST (0.16 as decimal(1, 1) returns 0.2 

but according to standard:
If least significant digits are lost, implementation-defined rounding or 
truncating occurs


  was:
Check:
ItDataTypesTest 

{noformat}
arguments(CaseStatus.SKIP, decimalType(5, 2), new BigDecimal("100.16"), 
decimalType(4, 1), bigDecimalVal("100.2")),
{noformat}

SELECT CAST(100.16::DECIMAL(5, 2) AS DECIMAL(4, 1)) returns 100.2 when called 
with dynamic parameters and truncated = 100.1 when called as literal


> Sql. Casting literals into numeric types have different rounding mode from 
> dynamic params
> -
>
> Key: IGNITE-20190
> URL: https://issues.apache.org/jira/browse/IGNITE-20190
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3
>
> Check:
> ItDataTypesTest 
> {noformat}
> arguments(CaseStatus.SKIP, decimalType(5, 2), new BigDecimal("100.16"), 
> decimalType(4, 1), bigDecimalVal("100.2")),
> {noformat}
> SELECT CAST(100.16::DECIMAL(5, 2) AS DECIMAL(4, 1)) returns 100.2 when called 
> with dynamic parameters and truncated = 100.1 when called as literal
> check, pg mysql and ora are rounding, not truncated i.e:
> SELECT CAST (0.16 as decimal(1, 1) returns 0.2 
> but according to standard:
> If least significant digits are lost, implementation-defined rounding or 
> truncating occurs



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

[jira] [Updated] (IGNITE-20188) Add improvements to the catalog associated with the DistributionZone #2

[Kirill Tkalenko (Jira)]

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

Kirill Tkalenko updated IGNITE-20188:
-
Description: 
During the implementation of IGNITE-20114, the following necessary improvements 
were discovered:
* Getting a zone from a catalog by ID and catalog version;
* Getting zones from a catalog by catalog version;
* Default zone has no data storage;
* If possible, improve the method of adding a catalog event listener, make it 
more generically;
* Create zone change listener in catalog and its fields;
* Add the ability to specify a data storage to the zone creation command in the 
conversion from dll.

  was:
During the implementation of IGNITE-20114, the following necessary improvements 
were discovered:
* Getting a zone from a catalog by ID and catalog version;
* Getting zones from a catalog by catalog version;
* Default zone has no data storage;
* If possible, improve the method of adding a catalog event listener, make it 
more generically;
* Create zone change listener in catalog and its fields.


> Add improvements to the catalog associated with the DistributionZone #2
> ---
>
> Key: IGNITE-20188
> URL: https://issues.apache.org/jira/browse/IGNITE-20188
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> During the implementation of IGNITE-20114, the following necessary 
> improvements were discovered:
> * Getting a zone from a catalog by ID and catalog version;
> * Getting zones from a catalog by catalog version;
> * Default zone has no data storage;
> * If possible, improve the method of adding a catalog event listener, make it 
> more generically;
> * Create zone change listener in catalog and its fields;
> * Add the ability to specify a data storage to the zone creation command in 
> the conversion from dll.



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

[jira] [Created] (IGNITE-20191) Sql. Extend test coverage for SORTED indexes

[Evgeny Stanilovsky (Jira)]

Evgeny Stanilovsky created IGNITE-20191:
---

 Summary: Sql. Extend test coverage for SORTED indexes
 Key: IGNITE-20191
 URL: https://issues.apache.org/jira/browse/IGNITE-20191
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky


Tests like : BaseIndexDataTypeTest are using default index implementation and 
seems we have pure coverage for SORTED indexes (using tree) the goal ot this 
issue is to extend tests for such king of indexes.



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

[jira] [Updated] (IGNITE-20191) Sql. Extend test coverage for SORTED indexes

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky updated IGNITE-20191:

Labels: ignite-3  (was: )

> Sql. Extend test coverage for SORTED indexes
> 
>
> Key: IGNITE-20191
> URL: https://issues.apache.org/jira/browse/IGNITE-20191
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3
>
> Tests like : BaseIndexDataTypeTest are using default index implementation and 
> seems we have pure coverage for SORTED indexes (using tree) the goal ot this 
> issue is to extend tests for such king of indexes.



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

[jira] [Updated] (IGNITE-19096) Sql. Remove code that replaces placeholder values from ModifyNode.

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky updated IGNITE-19096:

Ignite Flags:   (was: Docs Required,Release Notes Required)

> Sql. Remove code that replaces placeholder values from ModifyNode.
> --
>
> Key: IGNITE-19096
> URL: https://issues.apache.org/jira/browse/IGNITE-19096
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
>  Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> It is possible to remove default placeholders altogether and insert default 
> value s for columns at the sql to relnode conversion phase.
> *Note*
> A) In order to avoid code duplication use 
> TableDescriptorImpl::newColumnDefaultValue.
> B) Calcite generates different RelNode trees for queries INSERT INTO tmp (a) 
> VALUES (1) and INSERT INTO tmp (a, b) VALUES (1, DEFAULT). For the first 
> query calcite supplies DEFAULT values by calling 
> TableDescriptorImpl::newColumnDefaultValue, but for the second query it does 
> not do it.
> C) Since the values operator in Calcite can contain only literals, plans for 
> INSERT statements for tables with implicit primary key and without it are 
> different. When a table has an implicit primary key, Calcite adds a 
> projection operator with a call to gen_random_uuid() and uses values operator 
> as input of that projection.
>  



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