[jira] [Commented] (IGNITE-20429) Support dump check command

[Ignite TC Bot (Jira)]

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

Ignite TC Bot commented on IGNITE-20429:


{panel:title=Branch: [pull/10949/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code 
, TC_SERVICE_MESSAGE 
|https://ci2.ignite.apache.org/viewLog.html?buildId=7346479]]

{panel}
{panel:title=Branch: [pull/10949/head] Base: [master] : New Tests 
(34)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests 
17|https://ci2.ignite.apache.org/viewLog.html?buildId=7346018]]
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=true,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=ATOMIC]
 - PASSED{color}
... and 6 new tests

{color:#8b}Snapshots{color} [[tests 
17|https://ci2.ignite.apache.org/viewLog.html?buildId=7346001]]
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL]
 - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=ATOMIC]
 - PASSED{color}
... and 6 new tests

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7346021buildTypeId=IgniteTests24Java8_RunAll]

> Support dump check command
> --
>
> Key: IGNITE-20429
> 

[jira] [Commented] (IGNITE-20462) Idle_verify prints partitions hash conflicts when entries are expiring concurrently

[Ignite TC Bot (Jira)]

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

Ignite TC Bot commented on IGNITE-20462:


{panel:title=Branch: [pull/10947/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10947/head] Base: [master] : New Tests 
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests 
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7346471]]
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false,
 onlyPrimay=true] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false,
 onlyPrimay=false] - PASSED{color}

{color:#8b}Snapshots{color} [[tests 
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7344840]]
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false,
 onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false,
 onlyPrimay=false] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=true,
 onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite: 
IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=true,
 onlyPrimay=false] - PASSED{color}

{color:#8b}Control Utility 1{color} [[tests 
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7346473]]
* {color:#013220}IgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - 
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=jmx] - 
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite: 
GridCommandHandlerWithSslFactoryTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli]
 - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite: 
GridCommandHandlerWithSslTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - 
PASSED{color}

{color:#8b}Control Utility (Zookeeper){color} [[tests 
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7344796]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - 
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyDumpExpiringEntries[cmdHnd=cli] - 
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=jmx] - 
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite: 
GridCommandHandlerTest.testCacheIdleVerifyDumpExpiringEntries[cmdHnd=jmx] - 
PASSED{color}

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7344860buildTypeId=IgniteTests24Java8_RunAll]

> Idle_verify prints partitions hash conflicts when entries are expiring 
> concurrently
> ---
>
> Key: IGNITE-20462
> URL: https://issues.apache.org/jira/browse/IGNITE-20462
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: ise
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Background process of entries expire (ttl-cleaner-worker) always working on 
> activated cluster, so, during idle_verify execution entries still can be 
> expired even without workload on cluster. 



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

[jira] [Updated] (IGNITE-20477) Async component start

[Aleksandr Polovtcev (Jira)]

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

Aleksandr Polovtcev updated IGNITE-20477:
-
Description: 
Currently all Ignite components start synchronously (see 
{{IgniteComponent#start}}). This is inconvenient, because some components can 
complete their startup only when Meta Storage has initialized all Version 
Values (see {{IgniteImpl#recoverComponentsStateOnStart}}). Because of this, 
some components employ a hack which consists of having a "special" Versioned 
Value, which is injected with a future that gets resolved only after the 
enclosing component completes its startup (see {{startVv}} in {{TableManager}} 
or {{IndexManager}}). This blocks the Watch Processor inside Meta Storage, 
preventing it from processing further updates.

This problem with this approach that it is quite cryptic and hard to 
understand. Instead I propose to do the following:

# Change the signature of {{IgniteComponent#start}} to 
{{CompletableFuture start()}}.
# All actions in the components startup will be divided into two categories: 
sync actions, that can be executed synchronously in order for the component to 
be usable by other components during their startup, and async actions, which 
need to wait for any of the Versioned Values to be initialized by the Meta 
Storage. Such async actions should be wrapped in a {{CompletableFuture}} and 
returned from the {{start}} method.
# {{IgniteImpl}} startup procedure should be updated to collect the futures 
from all components and wait for their completion inside 
{{recoverComponentsStateOnStart}}, after 
{{metaStorageMgr.notifyRevisionUpdateListenerOnStart()}} has been called, but 
before Watches are deployed ({{metaStorageMgr.deployWatches()}}) 

> Async component start
> -
>
> Key: IGNITE-20477
> URL: https://issues.apache.org/jira/browse/IGNITE-20477
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
>
> Currently all Ignite components start synchronously (see 
> {{IgniteComponent#start}}). This is inconvenient, because some components can 
> complete their startup only when Meta Storage has initialized all Version 
> Values (see {{IgniteImpl#recoverComponentsStateOnStart}}). Because of this, 
> some components employ a hack which consists of having a "special" Versioned 
> Value, which is injected with a future that gets resolved only after the 
> enclosing component completes its startup (see {{startVv}} in 
> {{TableManager}} or {{IndexManager}}). This blocks the Watch Processor inside 
> Meta Storage, preventing it from processing further updates.
> This problem with this approach that it is quite cryptic and hard to 
> understand. Instead I propose to do the following:
> # Change the signature of {{IgniteComponent#start}} to 
> {{CompletableFuture start()}}.
> # All actions in the components startup will be divided into two categories: 
> sync actions, that can be executed synchronously in order for the component 
> to be usable by other components during their startup, and async actions, 
> which need to wait for any of the Versioned Values to be initialized by the 
> Meta Storage. Such async actions should be wrapped in a {{CompletableFuture}} 
> and returned from the {{start}} method.
> # {{IgniteImpl}} startup procedure should be updated to collect the futures 
> from all components and wait for their completion inside 
> {{recoverComponentsStateOnStart}}, after 
> {{metaStorageMgr.notifyRevisionUpdateListenerOnStart()}} has been called, but 
> before Watches are deployed ({{metaStorageMgr.deployWatches()}}) 



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

[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20471:
-
Description: 
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
{{NullPointerException}}. 

UPD1: 

It is possible that I was wrong and we even don't reach the code where we call 
invoke  {{replicaService.invoke(recipientNode)}}, because before we check 
{{groups.isEmpty()}} and seems that we go through the other branch.

Need to investigate why I've got {{null}} when run 
ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}}

  was:
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
{{NullPointerException}}. 


> Handle TxManagerImpl#finish correctly when recipientNode is null
> 
>
> Key: IGNITE-20471
> URL: https://issues.apache.org/jira/browse/IGNITE-20471
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> *Motivation*
> According the logic of invocations of {{TxManagerImpl#finish}}, it is 
> possible that {{recipientNode}}, which is passed to {{finish}}, could be 
> {{null}}. Further in the code of {{finish}} method we make 
> {{replicaService.invoke(recipientNode)}} and this could lead to 
> {{NullPointerException}}. 
> UPD1: 
> It is possible that I was wrong and we even don't reach the code where we 
> call invoke  {{replicaService.invoke(recipientNode)}}, because before we 
> check {{groups.isEmpty()}} and seems that we go through the other branch.
> Need to investigate why I've got {{null}} when run 
> ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}}



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

[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20471:
-
Description: 
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
{{NullPointerException}}. 

UPD1: 

It is possible that I was wrong and we even don't reach the code where we call 
invoke  {{replicaService.invoke(recipientNode)}}, because before we check 
{{groups.isEmpty()}} and seems that we go through the other branch.

Need to investigate why I've got {{null}} when run 
{{ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}}

  was:
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
{{NullPointerException}}. 

UPD1: 

It is possible that I was wrong and we even don't reach the code where we call 
invoke  {{replicaService.invoke(recipientNode)}}, because before we check 
{{groups.isEmpty()}} and seems that we go through the other branch.

Need to investigate why I've got {{null}} when run 
ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}}


> Handle TxManagerImpl#finish correctly when recipientNode is null
> 
>
> Key: IGNITE-20471
> URL: https://issues.apache.org/jira/browse/IGNITE-20471
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> *Motivation*
> According the logic of invocations of {{TxManagerImpl#finish}}, it is 
> possible that {{recipientNode}}, which is passed to {{finish}}, could be 
> {{null}}. Further in the code of {{finish}} method we make 
> {{replicaService.invoke(recipientNode)}} and this could lead to 
> {{NullPointerException}}. 
> UPD1: 
> It is possible that I was wrong and we even don't reach the code where we 
> call invoke  {{replicaService.invoke(recipientNode)}}, because before we 
> check {{groups.isEmpty()}} and seems that we go through the other branch.
> Need to investigate why I've got {{null}} when run 
> {{ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}}



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

[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20412:
-
Description: 
h3. Motivation

org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
 started to fall in the catalog-feature branch and fails in the main branch 
after catalog-feature is merged

[https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
{code:java}
java.lang.AssertionError:
Expected: is <[]>
 but: was <[A]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
at 
org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
{code}
h3. Implementation notes

The root cause:
 # This test changes metaStorageManager behavior and it throws expected 
exception on ms.invoke.
 # The test alters zone with new filter.
 # DistributionZoneManager#onUpdateFilter return a future from 
saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
 # The future is completed exceptionally and WatchProcessor#notificationFuture 
will be completed exceptionally.
 # Next updates will not be handled properly because notificationFuture is 
completed exceptionally.

We have already created tickets obout exception handling:
 * https://issues.apache.org/jira/browse/IGNITE-14693
 * https://issues.apache.org/jira/browse/IGNITE-14611

 

The test scenario is incorrect because the node should be stopped (by failure 
handler) if the ms.invoke failed. We need to rewrite it when the DZM restart 
will be updated.


UPD1:

I've tried to rewrite test, so we could not throw exception in metastorage 
handler, but just force thread to wait in this invoke, but this lead the to the 
problem that because we use spy on Standalone Metastorage, and mockito use 
synchronised block when we call ms.invoke, so that leads to the problem that 
blocking of one invoke leads to blocking all other communication with ms.

Need further investigation how to rewrite this test 

  was:
h3. Motivation

org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
 started to fall in the catalog-feature branch and fails in the main branch 
after catalog-feature is merged

[https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
{code:java}
java.lang.AssertionError:
Expected: is <[]>
 but: was <[A]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
at 
org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
{code}
h3. Implementation notes

The root cause:
 # This test changes metaStorageManager behavior and it throws expected 
exception on ms.invoke.
 # The test alters zone with new filter.
 # DistributionZoneManager#onUpdateFilter return a future from 
saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
 # The future is completed exceptionally and WatchProcessor#notificationFuture 
will be completed exceptionally.
 # Next updates will not be handled properly because notificationFuture is 
completed exceptionally.

We have already created tickets obout exception handling:
 * https://issues.apache.org/jira/browse/IGNITE-14693
 * https://issues.apache.org/jira/browse/IGNITE-14611

 

The test scenario is incorrect because the node should be stopped (by failure 
handler) if the ms.invoke failed. We need to rewrite it when the DZM restart 
will be updated.


> Fix 
> ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
> 
>
> Key: IGNITE-20412
> URL: https://issues.apache.org/jira/browse/IGNITE-20412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> h3. Motivation
> 

[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20339:
--
Fix Version/s: 3.0.0-beta2

> Get rid of IndexEvent and TableEvent
> 
>
> Key: IGNITE-20339
> URL: https://issues.apache.org/jira/browse/IGNITE-20339
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It was found that no one uses 
> *org.apache.ignite.internal.index.event.IndexEvent*, 
> *org.apache.ignite.internal.table.event.TableEvent* and 
> *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I 
> propose to get rid of this and related code.



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

[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20339:
--
Description: 
It was found that no one uses 
*org.apache.ignite.internal.index.event.IndexEvent*, 
*org.apache.ignite.internal.table.event.TableEvent* and 
*org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I 
propose to get rid of this and related code.



  was:It was found that no one uses 
*org.apache.ignite.internal.index.event.IndexEvent* and 
*org.apache.ignite.internal.table.event.TableEvent* except for tests, I propose 
to get rid of this and related code.


> Get rid of IndexEvent and TableEvent
> 
>
> Key: IGNITE-20339
> URL: https://issues.apache.org/jira/browse/IGNITE-20339
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
>
> It was found that no one uses 
> *org.apache.ignite.internal.index.event.IndexEvent*, 
> *org.apache.ignite.internal.table.event.TableEvent* and 
> *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I 
> propose to get rid of this and related code.



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

[jira] [Assigned] (IGNITE-20339) Get rid of IndexEvent and TableEvent

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov reassigned IGNITE-20339:
-

Assignee: Andrey Mashenkov

> Get rid of IndexEvent and TableEvent
> 
>
> Key: IGNITE-20339
> URL: https://issues.apache.org/jira/browse/IGNITE-20339
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
>
> It was found that no one uses 
> *org.apache.ignite.internal.index.event.IndexEvent* and 
> *org.apache.ignite.internal.table.event.TableEvent* except for tests, I 
> propose to get rid of this and related code.



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

[jira] [Updated] (IGNITE-20476) improve checking SQL exceptions in tests

[Yury Gerzhedovich (Jira)]

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

Yury Gerzhedovich updated IGNITE-20476:
---
Description: 
As of now there are few different approaches to check exception from SQLengine. 
It leads to hard control exceptions handling, like that all public Exception 
should be really public and don't belong to internal packages, or that all 
public exceptions have a text messages and so on.

 Let's move all exceptions checks related to SQL to two main points:
1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API
2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API

  was:
As of now there are few different approaches to check exception from SQLengine. 
It leads to hard control exceptions handling, like that all public Exception 
should be really public and don't belong to internal packages, or that all 
public exceptions have a text messages.

 Let's move all exceptions checks related to SQL to two main points:
1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API
2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API


> improve checking SQL exceptions in tests
> 
>
> Key: IGNITE-20476
> URL: https://issues.apache.org/jira/browse/IGNITE-20476
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now there are few different approaches to check exception from 
> SQLengine. It leads to hard control exceptions handling, like that all public 
> Exception should be really public and don't belong to internal packages, or 
> that all public exceptions have a text messages and so on.
>  Let's move all exceptions checks related to SQL to two main points:
> 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API
> 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API



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

[jira] [Assigned] (IGNITE-20385) Incorrect code INTERNAL_ERROR on node left

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin reassigned IGNITE-20385:
-

Assignee: Pavel Pereslegin

> Incorrect code INTERNAL_ERROR on node left 
> ---
>
> Key: IGNITE-20385
> URL: https://issues.apache.org/jira/browse/IGNITE-20385
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> During execute SQL query we could got Exception with INTERNAL_ERR in case 
> remote node left. Node left sholdn't be interpret as INTERNAL ERROR, due to 
> it's normal situation and user can be informed about it. 
> Let's map the situation to SqlException with code NODE_LEFT_ERR.
> Also need to check wich similar situation we could cover here.
> As start point need to find all places where used 
> ExceptionUtils.withCauseAndCode method
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
> TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment 
> [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
>   at 
> org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:106)
>   at 
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:100)
>   at 
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:76)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$15(ExecutionServiceImpl.java:747)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
>   at 
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:726)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
>   at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
>   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)
>   Suppressed: java.lang.RuntimeException: This is a trimmed root
>   ...
> Caused by: org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535 
> TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment 
> [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1]
>   at 
> org.apache.ignite.internal.util.ExceptionUtils.lambda$withCauseAndCode$3(ExceptionUtils.java:440)
>   at 
> org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:467)
>   at 
> org.apache.ignite.internal.util.ExceptionUtils.withCauseAndCode(ExceptionUtils.java:440)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$12(ExecutionServiceImpl.java:714)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
>   at 
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:698)
>   ... 7 more
> Caused by: org.apache.ignite.internal.sql.engine.NodeLeftException: IGN-CMN-5 
> TraceId:bf122f9c-e697-4dfa-b59f-0692595fa94c Node left the cluster. Node: 
> idt_n_1
>   at 
> 

[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.

[Pavel Pereslegin (Jira)]

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

Pavel Pereslegin updated IGNITE-20478:
--
Summary: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.  (was: 
Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row.)

> Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
> 
>
> Key: IGNITE-20478
> URL: https://issues.apache.org/jira/browse/IGNITE-20478
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> Currently, when scanning an index, we set a special value called 
> "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches 
> the bound (more details in IGNITE-16443).
> To be able to complete the transition to using a binary tuple, we need to 
> rework this approach and try to avoid storing non-conforming schema values in 
> row.



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

[jira] [Assigned] (IGNITE-20388) Sql. Migrate ClusterPerClassIntegrationTest to run queries via public api

[Yury Gerzhedovich (Jira)]

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

Yury Gerzhedovich reassigned IGNITE-20388:
--

Assignee: Yury Gerzhedovich

> Sql. Migrate ClusterPerClassIntegrationTest to run queries via public api
> -
>
> Key: IGNITE-20388
> URL: https://issues.apache.org/jira/browse/IGNITE-20388
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> ClusterPerClassIntegrationTest provides convenient shortcuts to run sql 
> queries {{ClusterPerClassIntegrationTest#sql}}). This shortcuts are used to 
> prepare cluster to run certain statements as well as validate in case of 
> errors certain exceptions are raised.
> The problem is that both these shortcuts uses internal api under the hood, 
> and internal api doesn't have exception conversion (by design). With that 
> said, it's possible to get {{CatalogValidationException}} where SqlException 
> with code STMT_VALIDATION_ERR was expected.
> Since vast majority of the tests using those shortcuts have e2e semantic, 
> it's better to change implementation of the shortcuts to use public api 
> instead. Tests that relies on internal api semantic, if any, should be 
> reworked to use different shortcuts.



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

[jira] [Created] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row.

[Pavel Pereslegin (Jira)]

Pavel Pereslegin created IGNITE-20478:
-

 Summary: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in 
row.
 Key: IGNITE-20478
 URL: https://issues.apache.org/jira/browse/IGNITE-20478
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Pavel Pereslegin


Currently, when scanning an index, we set a special value called 
"UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the 
bound (more details in IGNITE-16443).

To be able to complete the transition to using a binary tuple, we need to 
rework this approach and try to avoid storing non-conforming schema values in 
row.



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

[jira] [Created] (IGNITE-20477) Async component start

[Aleksandr Polovtcev (Jira)]

Aleksandr Polovtcev created IGNITE-20477:


 Summary: Async component start
 Key: IGNITE-20477
 URL: https://issues.apache.org/jira/browse/IGNITE-20477
 Project: Ignite
  Issue Type: Task
Reporter: Aleksandr Polovtcev






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

[jira] [Commented] (IGNITE-17882) Remove org.apache.ignite.binary.BinaryObject from public API

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky commented on IGNITE-17882:
-

[~mzhuravkov] thanks ! merged.

> Remove org.apache.ignite.binary.BinaryObject from public API
> 
>
> Key: IGNITE-17882
> URL: https://issues.apache.org/jira/browse/IGNITE-17882
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Maksim Zhuravkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It does not make sense to have BinaryObject interface in the public API until 
> IGNITE-14316 is resolved (this ticket should introduce the right interface(s) 
> at least).
> For now, let's just remove BinaryObject.



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

[jira] [Assigned] (IGNITE-19633) Exclude org.apache.calcite.plan.volcano from Javadoc

[Mikhail Pochatkin (Jira)]

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

Mikhail Pochatkin reassigned IGNITE-19633:
--

Assignee: Mikhail Pochatkin

> Exclude org.apache.calcite.plan.volcano from Javadoc 
> -
>
> Key: IGNITE-19633
> URL: https://issues.apache.org/jira/browse/IGNITE-19633
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Assigned] (IGNITE-20472) API to consumer cache dumps

[Nikolay Izhikov (Jira)]

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

Nikolay Izhikov reassigned IGNITE-20472:


Assignee: Nikolay Izhikov

> API to consumer cache dumps
> ---
>
> Key: IGNITE-20472
> URL: https://issues.apache.org/jira/browse/IGNITE-20472
> Project: Ignite
>  Issue Type: Task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-109, ise
>
> Ignite must provide API to consume cache dumps by user defined consumer.



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

[jira] [Comment Edited] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn edited comment on IGNITE-20376 at 9/22/23 10:48 AM:
---

Could not reproduce locally. Discussed with [~alapin] in private - this is most 
likely fixed by IGNITE-18856 . Closing this for now and keeping an eye on it.


was (Author: ptupitsyn):
Discussed with [~alapin] in private - this should be fixed by IGNITE-18856 . 
Closing this for now and keeping an eye on it.

> ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
> 
>
> Key: IGNITE-20376
> URL: https://issues.apache.org/jira/browse/IGNITE-20376
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ignite-20376.txt
>
>
> {code}
> java.util.concurrent.CompletionException: 
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
> IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica 
> has changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
> currentPrimaryReplicaTerm=2]
> {code}
> Looks like we should handle and retry *PrimaryReplicaMissException* in the 
> server streamer.



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

[jira] [Resolved] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn resolved IGNITE-20376.
-
Resolution: Fixed

> ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
> 
>
> Key: IGNITE-20376
> URL: https://issues.apache.org/jira/browse/IGNITE-20376
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ignite-20376.txt
>
>
> {code}
> java.util.concurrent.CompletionException: 
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
> IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica 
> has changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
> currentPrimaryReplicaTerm=2]
> {code}
> Looks like we should handle and retry *PrimaryReplicaMissException* in the 
> server streamer.



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

[jira] [Commented] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn commented on IGNITE-20376:
-

Discussed with [~alapin] in private - this should be fixed by IGNITE-18856 . 
Closing this for now and keeping an eye on it.

> ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
> 
>
> Key: IGNITE-20376
> URL: https://issues.apache.org/jira/browse/IGNITE-20376
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ignite-20376.txt
>
>
> {code}
> java.util.concurrent.CompletionException: 
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
> IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica 
> has changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
> currentPrimaryReplicaTerm=2]
> {code}
> Looks like we should handle and retry *PrimaryReplicaMissException* in the 
> server streamer.



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

[jira] [Assigned] (IGNITE-20476) improve checking SQL exceptions in tests

[Yury Gerzhedovich (Jira)]

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

Yury Gerzhedovich reassigned IGNITE-20476:
--

Assignee: Yury Gerzhedovich

> improve checking SQL exceptions in tests
> 
>
> Key: IGNITE-20476
> URL: https://issues.apache.org/jira/browse/IGNITE-20476
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: ignite-3
>
> As of now there are few different approaches to check exception from 
> SQLengine. It leads to hard control exceptions handling, like that all public 
> Exception should be really public and don't belong to internal packages, or 
> that all public exceptions have a text messages.
>  Let's move all exceptions checks related to SQL to two main points:
> 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API
> 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API



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

[jira] [Created] (IGNITE-20476) improve checking SQL exceptions in tests

[Yury Gerzhedovich (Jira)]

Yury Gerzhedovich created IGNITE-20476:
--

 Summary: improve checking SQL exceptions in tests
 Key: IGNITE-20476
 URL: https://issues.apache.org/jira/browse/IGNITE-20476
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Yury Gerzhedovich


As of now there are few different approaches to check exception from SQLengine. 
It leads to hard control exceptions handling, like that all public Exception 
should be really public and don't belong to internal packages, or that all 
public exceptions have a text messages.

 Let's move all exceptions checks related to SQL to two main points:
1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API
2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API



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

[jira] [Updated] (IGNITE-20475) .NET: Thin 3.0: EF Core provider

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20475:

Description: 
EF Core provider will allow using Ignite as any other DB supported by EF. 
This makes adoption incredibly easy for the users - a matter of a few changed 
lines to switch from Postgres/MsSQL/MySQL, keeping all existing code.
This is also a big undertaking and needs more investigation/PoC.

> .NET: Thin 3.0: EF Core provider
> 
>
> Key: IGNITE-20475
> URL: https://issues.apache.org/jira/browse/IGNITE-20475
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> EF Core provider will allow using Ignite as any other DB supported by EF. 
> This makes adoption incredibly easy for the users - a matter of a few changed 
> lines to switch from Postgres/MsSQL/MySQL, keeping all existing code.
> This is also a big undertaking and needs more investigation/PoC.



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

[jira] [Updated] (IGNITE-20473) Catalog service improvements

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20473:
--
Epic Name: Catalog Service part 2  (was: Catalog service part 2)

> Catalog service improvements
> 
>
> Key: IGNITE-20473
> URL: https://issues.apache.org/jira/browse/IGNITE-20473
> Project: Ignite
>  Issue Type: Epic
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
>
> Umbrella ticket for tech-debt and improvements after IGNITE-19502



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

[jira] [Created] (IGNITE-20475) .NET: Thin 3.0: EF Core provider

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-20475:
---

 Summary: .NET: Thin 3.0: EF Core provider
 Key: IGNITE-20475
 URL: https://issues.apache.org/jira/browse/IGNITE-20475
 Project: Ignite
  Issue Type: New Feature
  Components: platforms, 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] [Resolved] (IGNITE-19752) Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov resolved IGNITE-19752.
---
Resolution: Duplicate

> Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog
> --
>
> Key: IGNITE-19752
> URL: https://issues.apache.org/jira/browse/IGNITE-19752
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This umbrella ticket for refactoring of main Ignite 3 components to make them 
> using the Catalog. 
> Each of tickets separately may broke some functionality and test, so let's 
> merge them into a feature branch first.
> Once feature branch will be stable, let's merge all of them to the main at 
> once.



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

[jira] [Assigned] (IGNITE-19502) Separate component to keep database schema and manage changes in it

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov reassigned IGNITE-19502:
-

Assignee: Kirill Tkalenko

> Separate component to keep database schema and manage changes in it
> ---
>
> Key: IGNITE-19502
> URL: https://issues.apache.org/jira/browse/IGNITE-19502
> Project: Ignite
>  Issue Type: Epic
>  Components: persistence, sql
>Reporter: Sergey Chugunov
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> Right now database schema information in Ignite 3.0 is stored and treated as 
> regular configuration. All business processes related to schema changes are 
> distributed via  internal mechanisms of configuration engine and orchestrated 
> ad-hoc by consumer components like TableManager or IndexManager.
> But there is a strong evidence that API and guarantees of configuration 
> engine don't satisfy important requirements that emerge in the field of db 
> schema management.
> So we need to stop treating schema as any other configuration and move it to 
> a separate component called Catalog Service.
> This component will provide high-level API to modify the schema and will take 
> responsibility for all other necessary processes like synchronizing schema 
> changes between nodes, managing schema change events, notifying all necessary 
> components and providing orchestration between them.



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

[jira] [Updated] (IGNITE-19502) Separate component to keep database schema and manage changes in it

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19502:
--
Fix Version/s: 3.0.0-beta2

> Separate component to keep database schema and manage changes in it
> ---
>
> Key: IGNITE-19502
> URL: https://issues.apache.org/jira/browse/IGNITE-19502
> Project: Ignite
>  Issue Type: Epic
>  Components: persistence, sql
>Reporter: Sergey Chugunov
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Right now database schema information in Ignite 3.0 is stored and treated as 
> regular configuration. All business processes related to schema changes are 
> distributed via  internal mechanisms of configuration engine and orchestrated 
> ad-hoc by consumer components like TableManager or IndexManager.
> But there is a strong evidence that API and guarantees of configuration 
> engine don't satisfy important requirements that emerge in the field of db 
> schema management.
> So we need to stop treating schema as any other configuration and move it to 
> a separate component called Catalog Service.
> This component will provide high-level API to modify the schema and will take 
> responsibility for all other necessary processes like synchronizing schema 
> changes between nodes, managing schema change events, notifying all necessary 
> components and providing orchestration between them.



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

[jira] [Resolved] (IGNITE-19502) Separate component to keep database schema and manage changes in it

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov resolved IGNITE-19502.
---
Resolution: Fixed

> Separate component to keep database schema and manage changes in it
> ---
>
> Key: IGNITE-19502
> URL: https://issues.apache.org/jira/browse/IGNITE-19502
> Project: Ignite
>  Issue Type: Epic
>  Components: persistence, sql
>Reporter: Sergey Chugunov
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> Right now database schema information in Ignite 3.0 is stored and treated as 
> regular configuration. All business processes related to schema changes are 
> distributed via  internal mechanisms of configuration engine and orchestrated 
> ad-hoc by consumer components like TableManager or IndexManager.
> But there is a strong evidence that API and guarantees of configuration 
> engine don't satisfy important requirements that emerge in the field of db 
> schema management.
> So we need to stop treating schema as any other configuration and move it to 
> a separate component called Catalog Service.
> This component will provide high-level API to modify the schema and will take 
> responsibility for all other necessary processes like synchronizing schema 
> changes between nodes, managing schema change events, notifying all necessary 
> components and providing orchestration between them.



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

[jira] [Closed] (IGNITE-19752) Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov closed IGNITE-19752.
-

> Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog
> --
>
> Key: IGNITE-19752
> URL: https://issues.apache.org/jira/browse/IGNITE-19752
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This umbrella ticket for refactoring of main Ignite 3 components to make them 
> using the Catalog. 
> Each of tickets separately may broke some functionality and test, so let's 
> merge them into a feature branch first.
> Once feature branch will be stable, let's merge all of them to the main at 
> once.



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

[jira] [Updated] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20474:

Description: 
Currently, .NET thin client relies on reflection to emit 
serialization/deserialization code.  This approach is very flexible and 
user-friendly, but does not work with [Native 
AOT|https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows],
 which is getting increasingly popular.

Provide an additional serialization mechanism based on [Source 
Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview]
 that does not require reflection.

The difficult part is that we don't know the table schema at compile time.

  was:
Currently, .NET thin client relies on reflection to emit 
serialization/deserialization code.  This approach is very flexible and 
user-friendly, but does not work with AOT, which is getting increasingly 
popular.

Provide an additional serialization mechanism based on [Source 
Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview]
 that does not require reflection.

The difficult part is that we don't know the table schema at compile time.


> .NET: Thin 3.0: Source-generated serializer
> ---
>
> Key: IGNITE-20474
> URL: https://issues.apache.org/jira/browse/IGNITE-20474
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, .NET thin client relies on reflection to emit 
> serialization/deserialization code.  This approach is very flexible and 
> user-friendly, but does not work with [Native 
> AOT|https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows],
>  which is getting increasingly popular.
> Provide an additional serialization mechanism based on [Source 
> Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview]
>  that does not require reflection.
> The difficult part is that we don't know the table schema at compile time.



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

[jira] [Closed] (IGNITE-20293) Deal with CatalogService#latestCatalogVersion at the start of the components

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov closed IGNITE-20293.
-

> Deal with CatalogService#latestCatalogVersion at the start of the components
> 
>
> Key: IGNITE-20293
> URL: https://issues.apache.org/jira/browse/IGNITE-20293
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> At the moment, in some components, we have started using 
> *org.apache.ignite.internal.catalog.CatalogService#latestCatalogVersion* so 
> that we can get the latest state of the catalog after it is recovered.
> But this value is not immutable, so there may be consequences because of 
> this, we need to figure it out.



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

[jira] [Closed] (IGNITE-19852) Deal with RecoveryCompletionFutureFactory

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov closed IGNITE-19852.
-

> Deal with RecoveryCompletionFutureFactory
> -
>
> Key: IGNITE-19852
> URL: https://issues.apache.org/jira/browse/IGNITE-19852
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The main problem is described in IGNITE-19801, but due to the fact that we 
> now have code closely related to updating the configuration revision, it is 
> difficult to do everything at once in IGNITE-19801, so it will be divided 
> into parts.
> As part of ticket IGNITE-19777, we will have a new meta storage recovery 
> mechanism, so we need to do something with *RecoveryCompletionFutureFactory*, 
> I think that in general we can get rid of it, but this needs to be checked 
> more carefully.



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

[jira] [Updated] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20474:

Description: 
Currently, .NET thin client relies on reflection to emit 
serialization/deserialization code.  This approach is very flexible and 
user-friendly, but does not work with AOT, which is getting increasingly 
popular.

Provide an additional serialization mechanism based on [Source 
Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview]
 that does not require reflection.

The difficult part is that we don't know the table schema at compile time.

> .NET: Thin 3.0: Source-generated serializer
> ---
>
> Key: IGNITE-20474
> URL: https://issues.apache.org/jira/browse/IGNITE-20474
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, .NET thin client relies on reflection to emit 
> serialization/deserialization code.  This approach is very flexible and 
> user-friendly, but does not work with AOT, which is getting increasingly 
> popular.
> Provide an additional serialization mechanism based on [Source 
> Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview]
>  that does not require reflection.
> The difficult part is that we don't know the table schema at compile time.



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

[jira] [Updated] (IGNITE-20315) Add support for renaming a table column

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20315:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Add support for renaming a table column
> ---
>
> Key: IGNITE-20315
> URL: https://issues.apache.org/jira/browse/IGNITE-20315
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> At the moment there are tests for renaming table columns, but this function 
> is not supported in the catalog and SQL, I think it needs to be fixed.



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

[jira] [Updated] (IGNITE-20263) Get rid of DataStorageConfigurationSchema

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20263:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Get rid of DataStorageConfigurationSchema
> -
>
> Key: IGNITE-20263
> URL: https://issues.apache.org/jira/browse/IGNITE-20263
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to get rid of 
> *org.apache.ignite.internal.schema.configuration.storage.DataStorageConfigurationSchema*,
>  its descendants and the code associated with it.



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

[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20412:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Fix 
> ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
> 
>
> Key: IGNITE-20412
> URL: https://issues.apache.org/jira/browse/IGNITE-20412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> h3. Motivation
> org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
>  started to fall in the catalog-feature branch and fails in the main branch 
> after catalog-feature is merged
> [https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
> {code:java}
> java.lang.AssertionError:
> Expected: is <[]>
>  but: was <[A]>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at 
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
> at 
> org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
> {code}
> h3. Implementation notes
> The root cause:
>  # This test changes metaStorageManager behavior and it throws expected 
> exception on ms.invoke.
>  # The test alters zone with new filter.
>  # DistributionZoneManager#onUpdateFilter return a future from 
> saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
>  # The future is completed exceptionally and 
> WatchProcessor#notificationFuture will be completed exceptionally.
>  # Next updates will not be handled properly because notificationFuture is 
> completed exceptionally.
> We have already created tickets obout exception handling:
>  * https://issues.apache.org/jira/browse/IGNITE-14693
>  * https://issues.apache.org/jira/browse/IGNITE-14611
>  
> The test scenario is incorrect because the node should be stopped (by failure 
> handler) if the ms.invoke failed. We need to rewrite it when the DZM restart 
> will be updated.



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

[jira] [Updated] (IGNITE-20384) Clean up abandoned resources for destroyed tables in catalog

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20384:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Clean up abandoned resources for destroyed tables in catalog
> 
>
> Key: IGNITE-20384
> URL: https://issues.apache.org/jira/browse/IGNITE-20384
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> We need to clean up abandoned resources (from vault and metastore) for 
> destroyed tables from the catalog.
> Perhaps it will be two separate ticket.



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

[jira] [Updated] (IGNITE-20381) Add busyLock usage in CatalogManagerImpl

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20381:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Add busyLock usage in CatalogManagerImpl
> 
>
> Key: IGNITE-20381
> URL: https://issues.apache.org/jira/browse/IGNITE-20381
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> It was found that the *IgniteSpinBusyLock* is not used in 
> *org.apache.ignite.internal.catalog.CatalogManagerImpl*, this needs to be 
> fixed.



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

[jira] [Updated] (IGNITE-20287) Clean up abandoned resources for destroyed zones in catalog

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20287:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Clean up abandoned resources for destroyed zones in catalog
> ---
>
> Key: IGNITE-20287
> URL: https://issues.apache.org/jira/browse/IGNITE-20287
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> We need to clean up abandoned resources (from vault and metastore) for 
> destroyed distribution zones from the catalog.
> Perhaps it will be two separate ticket.



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

[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20339:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Get rid of IndexEvent and TableEvent
> 
>
> Key: IGNITE-20339
> URL: https://issues.apache.org/jira/browse/IGNITE-20339
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> It was found that no one uses 
> *org.apache.ignite.internal.index.event.IndexEvent* and 
> *org.apache.ignite.internal.table.event.TableEvent* except for tests, I 
> propose to get rid of this and related code.



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

[jira] [Updated] (IGNITE-20380) Try to deal with TableManager#assignmentsChangeListeners

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20380:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Try to deal with TableManager#assignmentsChangeListeners
> 
>
> Key: IGNITE-20380
> URL: https://issues.apache.org/jira/browse/IGNITE-20380
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
>
> *org.apache.ignite.internal.table.distributed.TableManager#assignmentsChangeListeners*
>  that are used in 
> *org.apache.ignite.client.handler.ClientInboundMessageHandler* have been 
> discovered and I would like to see if it would be possible to change these 
> listeners to catalog listeners for example or something like that.
> And also, most likely, the call of listeners should be made after writing to 
> the metastore.



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

[jira] [Updated] (IGNITE-20096) Fix building indexes after switch to Catalog

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20096:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Fix building indexes after switch to Catalog
> 
>
> Key: IGNITE-20096
> URL: https://issues.apache.org/jira/browse/IGNITE-20096
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When switch the *IndexManager* to the Catalog, a number of problems are 
> revealed, one of them is the building of indexes, it is proposed to solve 
> this problem separately so that the switch is smoother.



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

[jira] [Created] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-20474:
---

 Summary: .NET: Thin 3.0: Source-generated serializer
 Key: IGNITE-20474
 URL: https://issues.apache.org/jira/browse/IGNITE-20474
 Project: Ignite
  Issue Type: Improvement
  Components: platforms, 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-20046) Improve the Catalog interfaces

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20046:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Improve the Catalog interfaces
> --
>
> Key: IGNITE-20046
> URL: https://issues.apache.org/jira/browse/IGNITE-20046
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Catalog related interfaces and classes are missing javadocs, need to fix this.
> CatalogService getters, which accepts ID and timestamp, looks useless and, 
> probably, could be removed.
> Let's also change timestamp type `long->HybridTimestamp`



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

[jira] [Updated] (IGNITE-20051) Add startup recovery to CatalogSchemaManager

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20051:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Add startup recovery to CatalogSchemaManager
> 
>
> Key: IGNITE-20051
> URL: https://issues.apache.org/jira/browse/IGNITE-20051
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, {{CatalogSchemaManager}} does not implement a proper recovery 
> procedure at start. It needs a way to get all tables from the CatalogService 
> (including the dropped ones).



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

[jira] [Updated] (IGNITE-19790) Read range from metastore at start UpdateLogImpl

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19790:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Read range from metastore at start UpdateLogImpl
> 
>
> Key: IGNITE-19790
> URL: https://issues.apache.org/jira/browse/IGNITE-19790
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Now, in 
> *org.apache.ignite.internal.catalog.storage.UpdateLogImpl#restoreStateFromVault*,
>  versions are read from the volt, starting from 1, which is not correct 
> because the log can be cut off. We need to read from the metastore by range.



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

[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-20098:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Move exception classes related to distribution zones to an appropriate 
> package/module
> -
>
> Key: IGNITE-20098
> URL: https://issues.apache.org/jira/browse/IGNITE-20098
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Priority: Major
>  Labels: ignite-3
>




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

[jira] [Updated] (IGNITE-19719) Make CatalogDataStorageDescriptor support for each storage engine

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19719:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Make CatalogDataStorageDescriptor support for each storage engine
> -
>
> Key: IGNITE-19719
> URL: https://issues.apache.org/jira/browse/IGNITE-19719
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> At the moment, we do not have the ability to implement 
> *org.apache.ignite.internal.catalog.descriptors.CatalogDataStorageDescriptor* 
> for each storage engine, we need to come up with a mechanism for how to do 
> this.



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

[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment.

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19687:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Support default distribution zone reassignment.
> ---
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone 
> instance. All distribution zones are equals. Thus, conceptually, any zone can 
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is 
> currently assigned as default zone, must always exists.
> Let's 
> * Avoid using any hardcoded zone id or zone name for getting or detecting the 
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will 
> be responsible for resolving default zone if it is not specified when table 
> is creating.
> * Add a property in Configuration that will to default zone by zone id.
> * A distribution zone with name "Default"(?) and some default parameters must 
> be created on cluster initialization phase and an id, which was assigned to 
> such zone, must be stored to  Configuration.
> * Forbid dropping of distribution zone, which is currently marked as default.
> * Add support {{ALTER ZONE  SET DEFAULT}} to reassign default zone.
> * Allow renaming for all zones.



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

[jira] [Updated] (IGNITE-19680) Get rid of org.apache.ignite.internal.index.event.IndexEventParameters

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19680:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Get rid of org.apache.ignite.internal.index.event.IndexEventParameters
> --
>
> Key: IGNITE-19680
> URL: https://issues.apache.org/jira/browse/IGNITE-19680
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In the process of migrating to the catalog, we need to get rid of 
> *org.apache.ignite.internal.index.event.IndexEventParameters* (and related 
> classes) and use a different entity when working with indexes for sql.
> h2. Update
> The index creation/destroy event can be useful when building indexes.



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

[jira] [Updated] (IGNITE-19550) Reuse IDs of dropped Catalog objects for new objects

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19550:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Reuse IDs of dropped Catalog objects for new objects
> 
>
> Key: IGNITE-19550
> URL: https://issues.apache.org/jira/browse/IGNITE-19550
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In IGNITE-19524, we are switching from UUIDs to ints as IDs of the Catalog 
> objects (tables, indices, views, zones). Some users have use-cases where they 
> constantly create, drop and recreate same tables. In such cases, it might 
> make sense to reuse object IDs to slow down the growth of the global counter.
> A design is required.



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

[jira] [Updated] (IGNITE-19670) Improve CatalogService test coverage.

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19670:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Improve CatalogService test coverage.
> -
>
> Key: IGNITE-19670
> URL: https://issues.apache.org/jira/browse/IGNITE-19670
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Priority: Minor
>  Labels: ignite-3, tech-debt-test
>
> 1. CatalogServiceSelftTest.testCreateTable (+testDropTable) looks a bit 
> complicated. It checks creation of more than one table. Let's simplify the 
> test by reverting last changes
> 2. We use shared counter to generate unique identifier for schema objects. 
> Some tests checks schema object id, and some doesn't.  Let's move 
> schema-object's id check into separate test, to verify which command 
> increments the counter, and which doesn't.
> 3. Let's add a test that will check ABA problem. E.g. create-drop-create 
> table (or index) with same name and check the object can be resolved 
> correctly by name and by id (regarding object versioning in Catalog, of 
> course).



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

[jira] [Updated] (IGNITE-19549) Handle wrap-around of Catalog object IDs

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19549:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Handle wrap-around of Catalog object IDs
> 
>
> Key: IGNITE-19549
> URL: https://issues.apache.org/jira/browse/IGNITE-19549
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We are planning to switch from UUIDs to ints as Catalog object (tables, 
> indices, zones, views) IDs (IGNITE-19524). int allows 2/4 billion of values 
> (approx); if we add columns to the category of objects that need these IDs, 
> it seems theoretically possible to get into wrap-around situation.
> Design of some mechanism might be needed.
> (Although, in practice, it seems that WA cannot happen).



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

[jira] [Updated] (IGNITE-19643) Catalog validation code refactoring.

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19643:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Catalog validation code refactoring.
> 
>
> Key: IGNITE-19643
> URL: https://issues.apache.org/jira/browse/IGNITE-19643
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Priority: Minor
>  Labels: ignite-3, tech-debt
>
> Let's implement some validation rules that each Catalog command should check 
> before the execution. Then replace current boilerplate validation code with 
> applying these rules using Visitor pattern.



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

[jira] [Updated] (IGNITE-19082) Describe Catalog operation flow in README and cleanup dead code.

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19082:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Describe Catalog operation flow in README and cleanup dead code.
> 
>
> Key: IGNITE-19082
> URL: https://issues.apache.org/jira/browse/IGNITE-19082
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's 
> * ensure Catalog is used by default as a single schema management point by 
> TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. 
> * Describe CatalogService operations in README.md
> * drop schema related code from configuration.
> * drop outdated code from TableManager, IndexManager, SqlSchemaManager, 
> SchemaRegistry.
> * make a PR for merging feature branch to main (if applicable).
> * ensure there are end-to-end tests for the cases (if applicable) described 
> in CatalogServiceSelfTest. Also drop InternalSchemaTest.



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

[jira] [Updated] (IGNITE-19223) Implement accumulation of schema updates in CatalogService

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-19223:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Implement accumulation of schema updates in CatalogService
> --
>
> Key: IGNITE-19223
> URL: https://issues.apache.org/jira/browse/IGNITE-19223
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
>
> CatalogService implementation should hold the historical information about 
> schema updates. This means that:
>  # It needs to load the known history of schema updates on node start
>  # It should subsribe to new schema updates



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

[jira] [Updated] (IGNITE-18536) Schema synchronization feature and Catalog feature integration

[Andrey Mashenkov (Jira)]

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

Andrey Mashenkov updated IGNITE-18536:
--
Epic Link: IGNITE-20473  (was: IGNITE-19502)

> Schema synchronization feature and Catalog feature integration
> --
>
> Key: IGNITE-18536
> URL: https://issues.apache.org/jira/browse/IGNITE-18536
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Blocker
>  Labels: ignite-3
>
> Metadata synchronization should be used, implemented (most likely) on top of 
> "transactions in the past", defined in the transactions IEP (see "Lock-free 
> RW Transactions" in 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91:+Transaction+protocol).
> Let's plug SchemaSychronizationManager into Ignite node and use it for 
> waiting actual metadata before resolve actual Catalog version for a 
> transaction.



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

[jira] [Created] (IGNITE-20473) Catalog service improvements

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-20473:
-

 Summary: Catalog service improvements
 Key: IGNITE-20473
 URL: https://issues.apache.org/jira/browse/IGNITE-20473
 Project: Ignite
  Issue Type: Epic
Reporter: Andrey Mashenkov


Umbrella ticket for tech-debt and improvements after IGNITE-19502



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

[jira] [Commented] (IGNITE-20465) *.mvccEnabled() removal

[Ignite TC Bot (Jira)]

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

Ignite TC Bot commented on IGNITE-20465:


{panel:title=Branch: [pull/10945/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10945/head] Base: [master] : No new tests 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7344975buildTypeId=IgniteTests24Java8_RunAll]

> *.mvccEnabled() removal
> ---
>
> Key: IGNITE-20465
> URL: https://issues.apache.org/jira/browse/IGNITE-20465
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.16
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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

[jira] [Updated] (IGNITE-16088) Reuse Marshaller code in marshaller-common module

[Aleksandr Polovtcev (Jira)]

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

Aleksandr Polovtcev updated IGNITE-16088:
-
Fix Version/s: 3.0.0-beta2

> Reuse Marshaller code in marshaller-common module
> -
>
> Key: IGNITE-16088
> URL: https://issues.apache.org/jira/browse/IGNITE-16088
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 3.0.0-alpha4
>Reporter: Pavel Tupitsyn
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> IGNITE-14971 added *ignite-marshaller-common* module to reuse serialization 
> logic between the server and client parts.
> This module duplicates some logic from *ignite-schema* module.
> * Remove duplicated code from *ignite-schema* and reuse the logic from common 
> module.
> * Extract other common bits where applicable (e.g. *AsmSerializerGenerator*)



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

[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20367:
-
Description: 
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:f1535407-3cf9-48cd-9091-825ecf308526  at 
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
  at 
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
  at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
  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.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
  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.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
  at 
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
  at 

[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20367:
-
Description: 
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:f1535407-3cf9-48cd-9091-825ecf308526  at 
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
  at 
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
  at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
  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.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
  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.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
  at 
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
  at 

[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20367:
-
Description: 
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:f1535407-3cf9-48cd-9091-825ecf308526  at 
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
  at 
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
  at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
  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.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
  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.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
  at 
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
  at 

[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20367:
-
Description: 
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:f1535407-3cf9-48cd-9091-825ecf308526  at 
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
  at 
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
  at 
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
  at 
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
  at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448)  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
  at 
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
  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.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
  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.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
  at 
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
  at 

[jira] [Created] (IGNITE-20472) API to consumer cache dumps

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-20472:


 Summary: API to consumer cache dumps
 Key: IGNITE-20472
 URL: https://issues.apache.org/jira/browse/IGNITE-20472
 Project: Ignite
  Issue Type: Task
Reporter: Nikolay Izhikov


Ignite must provide API to consume cache dumps by user defined consumer.



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

[jira] [Updated] (IGNITE-20470) Ducktape to check dump performance

[Nikolay Izhikov (Jira)]

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

Nikolay Izhikov updated IGNITE-20470:
-
Labels: IEP-109 ise  (was: IEP-109)

> Ducktape to check dump performance
> --
>
> Key: IGNITE-20470
> URL: https://issues.apache.org/jira/browse/IGNITE-20470
> Project: Ignite
>  Issue Type: Task
>Reporter: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-109, ise
>
> Dump creation can affect transactions performance with change listener and 
> disc operations. We must create ducktape test to check this.
> Example test scenario:
> * Start nodes
> * Start transaction operations: insert, update, remove.
> * Create dump
> * Check dump consistency.
> Measure 
> * Transaction performance penalty.
> * GC utilization.
> * Disc utilization.



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

[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null

[Mirza Aliev (Jira)]

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

Mirza Aliev updated IGNITE-20471:
-
Description: 
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
{{NullPointerException}}. 

  was:
*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
NullPointerException. 


> Handle TxManagerImpl#finish correctly when recipientNode is null
> 
>
> Key: IGNITE-20471
> URL: https://issues.apache.org/jira/browse/IGNITE-20471
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> *Motivation*
> According the logic of invocations of {{TxManagerImpl#finish}}, it is 
> possible that {{recipientNode}}, which is passed to {{finish}}, could be 
> {{null}}. Further in the code of {{finish}} method we make 
> {{replicaService.invoke(recipientNode)}} and this could lead to 
> {{NullPointerException}}. 



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

[jira] [Created] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null

[Mirza Aliev (Jira)]

Mirza Aliev created IGNITE-20471:


 Summary: Handle TxManagerImpl#finish correctly when recipientNode 
is null
 Key: IGNITE-20471
 URL: https://issues.apache.org/jira/browse/IGNITE-20471
 Project: Ignite
  Issue Type: Bug
Reporter: Mirza Aliev


*Motivation*
According the logic of invocations of {{TxManagerImpl#finish}}, it is possible 
that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. 
Further in the code of {{finish}} method we make 
{{replicaService.invoke(recipientNode)}} and this could lead to 
NullPointerException. 



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

[jira] [Created] (IGNITE-20470) Ducktape to check dump performance

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-20470:


 Summary: Ducktape to check dump performance
 Key: IGNITE-20470
 URL: https://issues.apache.org/jira/browse/IGNITE-20470
 Project: Ignite
  Issue Type: Task
Reporter: Nikolay Izhikov


Dump creation can affect transactions performance with change listener and disc 
operations. We must create ducktape test to check this.

Example test scenario:

* Start nodes
* Start transaction operations: insert, update, remove.
* Create dump
* Check dump consistency.

Measure 
* Transaction performance penalty.
* GC utilization.
* Disc utilization.



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

[jira] [Updated] (IGNITE-20397) java.lang.AssertionError: Group of the event is unsupported

[Sergey Uttsel (Jira)]

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

Sergey Uttsel updated IGNITE-20397:
---
Description: 
{code:java}
  java.lang.AssertionError: Group of the event is unsupported 
[nodeId=<11_part_18/isaat_n_2>, 
event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
 ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
 ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137) 
~[disruptor-3.3.7.jar:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]

The root cause:
 # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from 
StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
 # In some cases the `subscribers` map is cleared by invocation of 
StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler 
receives event with SafeTimeSyncCommandImpl.
 # It produces an assertion error: `assert handler != null`

The issue is not caused by the catalog feature changes.

It possible to reproduced it if add Thread.sleep in StripeEntryHandler#onEvent.

Originally it was reproduced on a table dropping. But it possible to reproduce 
it on a table creation if set "IDLE_SAFE_TIME_PROPAGATION_PERIOD_MILLISECONDS = 
500;".

  was:
{code:java}
  java.lang.AssertionError: Group of the event is unsupported 
[nodeId=<11_part_18/isaat_n_2>, 
event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
 ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
 ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137) 
~[disruptor-3.3.7.jar:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]

The root cause:
 # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from 
StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
 # In some cases the `subscribers` map is cleared by invocation of 
StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler 
receives event with SafeTimeSyncCommandImpl.
 # It produces an assertion error: `assert handler != null`


> java.lang.AssertionError: Group of the event is unsupported
> ---
>
> Key: IGNITE-20397
> URL: https://issues.apache.org/jira/browse/IGNITE-20397
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
>  Labels: ignite-3
>
> {code:java}
>   java.lang.AssertionError: Group of the event is unsupported 
> [nodeId=<11_part_18/isaat_n_2>, 
> event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a]
> at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224)
>  ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
>  ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137) 
> ~[disruptor-3.3.7.jar:?]
> at java.lang.Thread.run(Thread.java:834) ~[?:?] {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true=true=false=true=false=true]
> The root cause:
>  # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from 
> StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId().
>  # In some cases the `subscribers` map is cleared by invocation of 
> StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler 
> receives event with SafeTimeSyncCommandImpl.
>  # It produces an assertion error: `assert handler != null`
> The issue is not caused by the catalog feature changes.
> It possible to reproduced it if add Thread.sleep in 
> StripeEntryHandler#onEvent.
> Originally it was reproduced on a table dropping. But it possible to 
> reproduce it on a table creation if set 
> "IDLE_SAFE_TIME_PROPAGATION_PERIOD_MILLISECONDS = 500;".



--
This message was sent by Atlassian Jira

[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart

[Sergey Uttsel (Jira)]

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

Sergey Uttsel updated IGNITE-20412:
---
Description: 
h3. Motivation

org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
 started to fall in the catalog-feature branch and fails in the main branch 
after catalog-feature is merged

[https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
{code:java}
java.lang.AssertionError:
Expected: is <[]>
 but: was <[A]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
at 
org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
{code}
h3. Implementation notes

The root cause:
 # This test changes metaStorageManager behavior and it throws expected 
exception on ms.invoke.
 # The test alters zone with new filter.
 # DistributionZoneManager#onUpdateFilter return a future from 
saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
 # The future is completed exceptionally and WatchProcessor#notificationFuture 
will be completed exceptionally.
 # Next updates will not be handled properly because notificationFuture is 
completed exceptionally.

We have already created tickets obout exception handling:
 * https://issues.apache.org/jira/browse/IGNITE-14693
 * https://issues.apache.org/jira/browse/IGNITE-14611

 

The test scenario is incorrect because the node should be stopped (by failure 
handler) if the ms.invoke failed. We need to rewrite it when the DZM restart 
will be updated.

  was:
h3. Motivation

org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
 started to fall in the catalog-feature branch and fails in the main branch 
after catalog-feature is merged

https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=

{code:java}
java.lang.AssertionError:
Expected: is <[]>
 but: was <[A]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at 
org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459)
at 
org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539)
{code}

h3. Implementation notes

The root cause:
# This test changes metaStorageManager behavior and it throws expected 
exception on ms.invoke.
# The test alters zone with new filter.
# DistributionZoneManager#onUpdateFilter return a future from 
saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken)
# The future is completed exceptionally and WatchProcessor#notificationFuture 
will be completed exceptionally.
# Next updates will not be handled properly because notificationFuture is 
completed exceptionally.

We have already created tickets obout exception handling:
* https://issues.apache.org/jira/browse/IGNITE-14693 
* https://issues.apache.org/jira/browse/IGNITE-14611 

I think the test scenario is incorrect because the node should be stopped (by 
failure handler) if the ms.invoke failed.


> Fix 
> ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
> 
>
> Key: IGNITE-20412
> URL: https://issues.apache.org/jira/browse/IGNITE-20412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> h3. Motivation
> org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
>  started to fall in the catalog-feature branch and fails in the main branch 
> after catalog-feature is merged
> [https://ci.ignite.apache.org/viewLog.html?buildId=7501721=buildResultsDiv=ApacheIgnite3xGradle_Test_RunAllTests=]
> {code:java}
> java.lang.AssertionError:
> Expected: is <[]>
>  but: was <[A]>
> at 

[jira] [Updated] (IGNITE-20469) Sql. improve usability of EXPLAIN

[Yury Gerzhedovich (Jira)]

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

Yury Gerzhedovich updated IGNITE-20469:
---
Description: Let's try to improve usability output of EXPLAIN command. We 
could use different levels/verbose. Default level should be the simplest, but 
more verbose should help to advanced users/developer understand what is going 
on more deeply.

> Sql. improve usability of EXPLAIN
> -
>
> Key: IGNITE-20469
> URL: https://issues.apache.org/jira/browse/IGNITE-20469
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>  Labels: ignite-3
>
> Let's try to improve usability output of EXPLAIN command. We could use 
> different levels/verbose. Default level should be the simplest, but more 
> verbose should help to advanced users/developer understand what is going on 
> more deeply.



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

[jira] [Created] (IGNITE-20469) Sql. improve usability of EXPLAIN

[Yury Gerzhedovich (Jira)]

Yury Gerzhedovich created IGNITE-20469:
--

 Summary: Sql. improve usability of EXPLAIN
 Key: IGNITE-20469
 URL: https://issues.apache.org/jira/browse/IGNITE-20469
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Yury Gerzhedovich






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

[jira] [Updated] (IGNITE-20424) [Thin clients] Slow thin clients connection can lead to huge amount heap consuming

[Mikhail Petrov (Jira)]

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

Mikhail Petrov updated IGNITE-20424:

Summary: [Thin clients] Slow thin clients connection can lead to huge 
amount heap consuming  (was: [Thin clients] Slow thin clients connection can 
lead to node failure with OOM)

> [Thin clients] Slow thin clients connection can lead to huge amount heap 
> consuming
> --
>
> Key: IGNITE-20424
> URL: https://issues.apache.org/jira/browse/IGNITE-20424
> Project: Ignite
>  Issue Type: Task
>Reporter: Mikhail Petrov
>Priority: Major
>  Labels: ise
>
> All messages designated for the thin client are accumulated in the selector 
> queue GridSelectorNioSessionImpl#queue before they are sent. Note that  
> GridSelectorNioSessionImpl#queue  is unbound. If the thin client connection 
> is slow and a huge number of messages with a large weight will be sent to it, 
> GridSelectorNioSessionImpl#queue growing size can lead to OOM.
> See 
> 1. https://issues.apache.org/jira/browse/IGNITE-20327  
> 2. https://github.com/apache/ignite/issues/10559
> We need to investigate mechanisms to limit the thin client message queue size.



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

[jira] [Assigned] (IGNITE-20055) Durable txCleanupReplicaRequest send from the commit partition

[Jira]

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

 Kirill Sizov reassigned IGNITE-20055:
--

Assignee:  Kirill Sizov

> Durable txCleanupReplicaRequest send from the commit partition
> --
>
> Key: IGNITE-20055
> URL: https://issues.apache.org/jira/browse/IGNITE-20055
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee:  Kirill Sizov
>Priority: Major
>  Labels: ignite-3, transaction3_recovery, transactions
>
> h3. Motivation
> It's required to continuously send txCleanupReplicaRequest to the primary 
> replica. Suggested flow is following.
> h3. Definition of Done
>  # Resend exact the same type of finish output that was initially evaluated, 
> meaning that commit will be resent infinitely even if previous 
> txCleanupReplicaRequest returns an exception.
>  # Await commit partition primary replica appearance in case of initially 
> enlisted recipient failure.
>  



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

[jira] [Updated] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn updated IGNITE-20376:

Description: 
{code}
java.util.concurrent.CompletionException: 
org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica has 
changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
currentPrimaryReplicaTerm=2]
{code}

Looks like we should handle and retry *PrimaryReplicaMissException* in the 
server streamer.

  was:
{code}
java.util.concurrent.CompletionException: 
org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica has 
changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
currentPrimaryReplicaTerm=2]
{code}


> ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
> 
>
> Key: IGNITE-20376
> URL: https://issues.apache.org/jira/browse/IGNITE-20376
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: ignite-20376.txt
>
>
> {code}
> java.util.concurrent.CompletionException: 
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: 
> IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica 
> has changed because the term has been changed [expectedPrimaryReplicaTerm=1, 
> currentPrimaryReplicaTerm=2]
> {code}
> Looks like we should handle and retry *PrimaryReplicaMissException* in the 
> server streamer.



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

[jira] [Created] (IGNITE-20468) .NET: Thin 3.0: Intermittent timeouts on TC

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-20468:
---

 Summary: .NET: Thin 3.0: Intermittent timeouts on TC
 Key: IGNITE-20468
 URL: https://issues.apache.org/jira/browse/IGNITE-20468
 Project: Ignite
  Issue Type: Bug
  Components: platforms, thin client
Affects Versions: 3.0.0-beta1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 3.0.0-beta2


Increased number of .NET TC builds fail with timeout errors. Investigate 
whether some specific test or behavior is causing this, whether this is a 
problem on server side, etc

* 
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests?branch=%3Cdefault%3E=builds#all-projects
* `Fail to issue RPC to 
org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, 
consecutiveErrorTimes=10, error=Status[ETIMEDOUT<1010>: RPC exception:null]`
* `OneTimeSetUp: System.TimeoutException : The operation has timed out.`
** Which operation? Why is there no stack trace?




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

[jira] [Assigned] (IGNITE-20447) Introduce a new failure handling component

[Sergey Uttsel (Jira)]

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

Sergey Uttsel reassigned IGNITE-20447:
--

Assignee: Sergey Uttsel

> Introduce a new failure handling component
> --
>
> Key: IGNITE-20447
> URL: https://issues.apache.org/jira/browse/IGNITE-20447
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vyacheslav Koptilin
>Assignee: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
>
> Let's add a new component `failure` to Apache Ignite 3 and add base 
> interfaces to this component.
> *Definition of done:*
>  - introduced a new module to Ignite 3 codebase
>  - introduced a new Ignite component - _FailureProcessor _with minimal no-op 
> implementation. This component is responsible for processing critical errors.
>  - introduced a new _FailureHandler _interface. An implementation of this 
> interface represents a concrete strategy for handling errors.
>  - introduced a new enum _FailureType _that describes a possible type of 
> failure. The following types can be considered as a starting point: 
> _CRITICAL_ERROR_, _SYSTEM_WORKER_TERMINATION_, _SYSTEM_WORKER_BLOCKED_, 
> _SYSTEM_CRITICAL_OPERATION_TIMEOUT_
>  - introduced a new class _FailureContext _that contains information about 
> failure type and exception.
> *Implemenattion notes:*
> All these classes and interfaces should be a part of internal API due to 
> the end user should not provide a custom implementation of the failure 
> handler, Apache Ignite should provide a closed list of handlers out of the 
> box.



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

[jira] [Commented] (IGNITE-20399) .NET: Thin 3.0: TestSchemaUpdateWhileStreaming fails with IncompatibleSchemaException

[Pavel Tupitsyn (Jira)]

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

Pavel Tupitsyn commented on IGNITE-20399:
-

Merged to main: c6d1d0b230caa3d5cc6c5d502fb50958d5bcd5d0

> .NET: Thin 3.0: TestSchemaUpdateWhileStreaming fails with 
> IncompatibleSchemaException
> -
>
> Key: IGNITE-20399
> URL: https://issues.apache.org/jira/browse/IGNITE-20399
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *TestSchemaUpdateWhileStreaming* fails due to ALTER TABLE happening between 
> an implicit tx start and commit
> {code}
> Apache.Ignite.IgniteException : Table schema was updated after the 
> transaction was started [table=93, startSchema=1, operationSchema=2]
> > Apache.Ignite.IgniteException : 
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
>  IGN-TX-12 TraceId:db7e4055-c764-46fb-a141-d17a61d8bedc Table schema was 
> updated after the transaction was started [table=93, startSchema=1, 
> operationSchema=2]
> at 
> org.apache.ignite.internal.table.distributed.replicator.SchemaCompatValidator.failIfSchemaChangedAfterTxStart(SchemaCompatValidator.java:183)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.failIfSchemaChangedSinceTxStart(PartitionReplicaListener.java:2693)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$validateAtTimestampAndBuildUpdateAllCommand$168(PartitionReplicaListener.java:2766)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at 
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateAllCommand(PartitionReplicaListener.java:2765)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateAllCommand(PartitionReplicaListener.java:2714)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processMultiEntryAction$93(PartitionReplicaListener.java:1775)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at 
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processMultiEntryAction(PartitionReplicaListener.java:1761)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$4(PartitionReplicaListener.java:379)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1505)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:379)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$invoke$0(PartitionReplicaListener.java:355)
> at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at 
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at 
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at 
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at 
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at 

[jira] [Created] (IGNITE-20467) Use replica message instead of directly using raft client when building indexes

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-20467:


 Summary: Use replica message instead of directly using raft client 
when building indexes
 Key: IGNITE-20467
 URL: https://issues.apache.org/jira/browse/IGNITE-20467
 Project: Ignite
  Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 3.0.0-beta2


*org.apache.ignite.internal.table.distributed.index.IndexBuilder* uses a raft 
client, I think it’s worth changing this to using a replication message to get 
rid of the implementation of the replication protocol.



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

[jira] [Assigned] (IGNITE-19894) Sql. Can`t access column created in lower registry through Tuple api

[Evgeny Stanilovsky (Jira)]

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

Evgeny Stanilovsky reassigned IGNITE-19894:
---

Assignee: Evgeny Stanilovsky

> Sql. Can`t access column created in lower registry through Tuple api
> 
>
> Key: IGNITE-19894
> URL: https://issues.apache.org/jira/browse/IGNITE-19894
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3
>
> Starting point for example [1]
> {code:java}
> checkDdl(true, ses, "CREATE TABLE my (c1 INT PRIMARY KEY, c2 INT, c3 
> VARCHAR)");
> Session ses = sql.createSession();
> result.intValue("C2"); <--- Ok
> result.intValue("c2"); <--- throws Column doesn't exist [name=c2]
> {code}
> [1] InternalSchemaTest#testDropAndAddColumns
> Seems quotations at all not supported by now, 
> DdlSqlToCommandConverter#convertCreateTable



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

[jira] [Commented] (IGNITE-20399) .NET: Thin 3.0: TestSchemaUpdateWhileStreaming fails with IncompatibleSchemaException

[Igor Sapego (Jira)]

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

Igor Sapego commented on IGNITE-20399:
--

Looks good.

> .NET: Thin 3.0: TestSchemaUpdateWhileStreaming fails with 
> IncompatibleSchemaException
> -
>
> Key: IGNITE-20399
> URL: https://issues.apache.org/jira/browse/IGNITE-20399
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> *TestSchemaUpdateWhileStreaming* fails due to ALTER TABLE happening between 
> an implicit tx start and commit
> {code}
> Apache.Ignite.IgniteException : Table schema was updated after the 
> transaction was started [table=93, startSchema=1, operationSchema=2]
> > Apache.Ignite.IgniteException : 
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
>  IGN-TX-12 TraceId:db7e4055-c764-46fb-a141-d17a61d8bedc Table schema was 
> updated after the transaction was started [table=93, startSchema=1, 
> operationSchema=2]
> at 
> org.apache.ignite.internal.table.distributed.replicator.SchemaCompatValidator.failIfSchemaChangedAfterTxStart(SchemaCompatValidator.java:183)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.failIfSchemaChangedSinceTxStart(PartitionReplicaListener.java:2693)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$validateAtTimestampAndBuildUpdateAllCommand$168(PartitionReplicaListener.java:2766)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at 
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateAllCommand(PartitionReplicaListener.java:2765)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateAllCommand(PartitionReplicaListener.java:2714)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processMultiEntryAction$93(PartitionReplicaListener.java:1775)
> at 
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at 
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processMultiEntryAction(PartitionReplicaListener.java:1761)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$4(PartitionReplicaListener.java:379)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1505)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:379)
> at 
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$invoke$0(PartitionReplicaListener.java:355)
> at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at 
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at 
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at 
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at 
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at 
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at 
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at 
>