[
https://issues.apache.org/jira/browse/IGNITE-19342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19342:
---------------------------------
Description:
{{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
was:
{{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 highly likely connected to the fact, that metastorage and configuration do
not share the same storage
> 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
> Priority: Major
> Labels: ignite-3
>
> {{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)
