[
https://issues.apache.org/jira/browse/IGNITE-19440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19440:
-------------------------------------
Description:
h3. Motivation
While reviewing https://issues.apache.org/jira/browse/IGNITE-18955 it became
obvious that having zone specific details in
TableManager#createDistributionZonesDataNodesListener and partial dataNodes
emptiness check is a result of bad design and should be fixed ASAP. The core
idea here is that instead of TableManager, distribution Zones should manage
rebalance so that it's worth to move all corresponding listeners to an
appropriate place. Unfortunately it's not that easy because some listeners are
coupled with table logic too tight but aforementioned
createDistributionZonesDataNodesListener and onUpdateReplicas not of that kind,
they are easy to move and thus might be considered as good candidates to start
with.
Besides moving listeners that update pending assignments keys it's also worth
to substitute baselineManager usage with dataNodes one in onUpdateReplicas in
order to provide an ability to add filter appliance and dataNodes emptiness
check there.
h3. Definition of Done
* Both createDistributionZonesDataNodesListener and onUpdateReplicas are moved
from TableManager to distribution zones.
* Within onUpdateReplicas baselineManager#nodes usage is substituted with
dataNodes one in order apply filter and emptiness check.
h3. Implementation Notes
* createDistributionZonesDataNodesListener and onUpdateReplicas were moved
from TableManager to newly created DistributionZoneRebalanceEngine. This new
class was created in order to encapsulate rebalance related logic and thus not
to put it DistributionZoneManager itself which is already overloaded. It worth
to mention that DistributionZoneRebalanceEngine isn't an ignite component and
thus it's managed by DZM. Not sure whether it's better to have rebalance
engine as root component within its one module or current approach is fine
enough, we will see later on.
* Only two changes were made inside createDistributionZonesDataNodesListener
and onUpdateReplicas
** Within onUpdateReplicas baselineManager#nodes was substitutes with
dzm.getDataNodesById()
** Assignments emptiness check were added.
* Aforementioned refactoring is partial one, biggest part of rebalance related
logic still located in TableManager, meaning that only pending assignments
calculation on rebalance initialization was moved, thus
** RebalanceUtil was spitted in a way that new RebalanceUtil with
updatePendingAssignmentsKeys was created in distribution zones module along
with corresponding original RebalanceUtil updated. It worth to mention that
eventually RebalanceUtil in tables module will be removed.
** TablePartitionId was duplicated, now we have same classes in both zones and
tables module. Same as above, eventually that will be fixed.
* TableManagerDistributionZonesTest was refactored, it was renamed to
DistributionZoneRebalanceEngineTest and changed internally.
* asd
was:
h3. Motivation
While reviewing https://issues.apache.org/jira/browse/IGNITE-18955 it became
obvious that having zone specific details in
TableManager#createDistributionZonesDataNodesListener and partial dataNodes
emptiness check is a result of bad design and should be fixed ASAP. The core
idea here is that instead of TableManager, distribution Zones should manage
rebalance so that it's worth to move all corresponding listeners to an
appropriate place. Unfortunately it's not that easy because some listeners are
coupled with table logic too tight but aforementioned
createDistributionZonesDataNodesListener and onUpdateReplicas not of that kind,
they are easy to move and thus might be considered as good candidates to start
with.
Besides moving listeners that update pending assignments keys it's also worth
to substitute baselineManager usage with dataNodes one in onUpdateReplicas in
order to provide an ability to add filter appliance and dataNodes emptiness
check there.
h3. Definition of Done
* Both createDistributionZonesDataNodesListener and onUpdateReplicas are moved
from TableManager to distribution zones.
* Within onUpdateReplicas baselineManager#nodes usage is substituted with
dataNodes one in order apply filter and emptiness check.
> Move onUpdateReplicas and distributionZonesDataNodesListener from table
> manager to distribution zones
> -----------------------------------------------------------------------------------------------------
>
> Key: IGNITE-19440
> URL: https://issues.apache.org/jira/browse/IGNITE-19440
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Alexander Lapin
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> While reviewing https://issues.apache.org/jira/browse/IGNITE-18955 it became
> obvious that having zone specific details in
> TableManager#createDistributionZonesDataNodesListener and partial dataNodes
> emptiness check is a result of bad design and should be fixed ASAP. The core
> idea here is that instead of TableManager, distribution Zones should manage
> rebalance so that it's worth to move all corresponding listeners to an
> appropriate place. Unfortunately it's not that easy because some listeners
> are coupled with table logic too tight but aforementioned
> createDistributionZonesDataNodesListener and onUpdateReplicas not of that
> kind, they are easy to move and thus might be considered as good candidates
> to start with.
> Besides moving listeners that update pending assignments keys it's also worth
> to substitute baselineManager usage with dataNodes one in onUpdateReplicas in
> order to provide an ability to add filter appliance and dataNodes emptiness
> check there.
> h3. Definition of Done
> * Both createDistributionZonesDataNodesListener and onUpdateReplicas are
> moved from TableManager to distribution zones.
> * Within onUpdateReplicas baselineManager#nodes usage is substituted with
> dataNodes one in order apply filter and emptiness check.
> h3. Implementation Notes
> * createDistributionZonesDataNodesListener and onUpdateReplicas were moved
> from TableManager to newly created DistributionZoneRebalanceEngine. This new
> class was created in order to encapsulate rebalance related logic and thus
> not to put it DistributionZoneManager itself which is already overloaded. It
> worth to mention that DistributionZoneRebalanceEngine isn't an ignite
> component and thus it's managed by DZM. Not sure whether it's better to have
> rebalance engine as root component within its one module or current approach
> is fine enough, we will see later on.
> * Only two changes were made inside createDistributionZonesDataNodesListener
> and onUpdateReplicas
> ** Within onUpdateReplicas baselineManager#nodes was substitutes with
> dzm.getDataNodesById()
> ** Assignments emptiness check were added.
> * Aforementioned refactoring is partial one, biggest part of rebalance
> related logic still located in TableManager, meaning that only pending
> assignments calculation on rebalance initialization was moved, thus
> ** RebalanceUtil was spitted in a way that new RebalanceUtil with
> updatePendingAssignmentsKeys was created in distribution zones module along
> with corresponding original RebalanceUtil updated. It worth to mention that
> eventually RebalanceUtil in tables module will be removed.
> ** TablePartitionId was duplicated, now we have same classes in both zones
> and tables module. Same as above, eventually that will be fixed.
> * TableManagerDistributionZonesTest was refactored, it was renamed to
> DistributionZoneRebalanceEngineTest and changed internally.
> * asd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
