[jira] [Commented] (IGNITE-19342) Use DistributedConfigurationStrorage in the several test classes of the DistributionZone module.

["Alexander Lapin (Jira)" <ji...@apache.org>]

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

Alexander Lapin commented on IGNITE-19342:
------------------------------------------

[~Sergey Uttsel] LGTM, Thanks!

> Use DistributedConfigurationStrorage in the several test classes of the DistributionZone module.
> ------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-19342
>                 URL: https://issues.apache.org/jira/browse/IGNITE-19342
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Mirza Aliev
>            Assignee: Sergey Uttsel
>            Priority: Blocker
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>
> {{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleUpTriggersDataNodePropagation}}, {{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleDownTriggersDataNodePropagation}} - this tests fail with the following assertion error: Expected revision that is greater or equal to already seen meta storage events. This is because {{TestConfigurationStorage}} does not use the same revision as the Meta Storage, therefore their revisions can't be compared directly. We should use {{DistributedConfigurationStrorage}} instead, so configuration will use the same revisions, as the metastorage.
> Also {{DistributionZoneManagerScaleUpTest#testDropZoneDoNotPropagateDataNodesAfterScaleUp}}, {{DistributionZoneManagerScaleUpTest#testDropZoneDoNotPropagateDataNodesAfterScaleDown}} failures can be fixed with the introduction of {{DistributedConfigurationStrorage}} in the DistributionZoneManagerScaleUpTest - this test is flaky, because notifications from test configuration storage and from Meta Storage Watches are not related to each other (unlike real-life Distributed Configuration Storage which is built on top of Watches), so notifications from the configuration storage and Meta Storage can arrive in a undetermined order.
> Also {{DistributionZoneManagerWatchListenerTest#testDataNodesOfDefaultZoneUpdatedOnWatchListenerEvent}} could be fixed after introduction of {{DistributedConfigurationStrorage}}  in DistributionZoneManagerWatchListenerTest - this test is flaky, probably due to some races between Watch and Configuration Listener execution (sometimes a retry on invoke happens and Mockito#verify fails).
> Test {{DistributionZoneManagerScaleUpTest#testDataNodesPropagationAfterScaleUpTriggered}} could fail with 
> {noformat}
> java.lang.AssertionError: 
> Expected: is <1L>
>      but: was <3L>
> java.lang.AssertionError:
> Expected: is <1L>
>      but: was <3L>
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
>   at org.apache.ignite.internal.distributionzones.util.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:211)
>   at org.apache.ignite.internal.distributionzones.util.DistributionZonesTestUtil.assertZoneScaleUpChangeTriggerKey(DistributionZonesTestUtil.java:80)
>   at org.apache.ignite.internal.distributionzones.DistributionZoneManagerScaleUpTest.testDataNodesPropagationAfterScaleUpTriggered(DistributionZoneManagerScaleUpTest.java:107)
> {noformat}
> This is highly likely connected to the same fact, that metastorage and configuration do not share the same storage



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