[
https://issues.apache.org/jira/browse/HDDS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484297#comment-16484297
]
Elek, Marton commented on HDDS-91:
----------------------------------
Thanks the review [~anu].
Summarizing an IRL discussion: yes, this part will be changed in the SCM part
very soon. This is more like an example for the integration of the EventQueue.
If you are agree with the high level approach of this patch, I will close this
and integrate the event queue with the same way but with SCMNodeManager with
sending a DEAD_NODE event from moveStaleNodeToDead.moveStaleNodeToDead.
> Calculate under/over replicated containers from the container reports
> ---------------------------------------------------------------------
>
> Key: HDDS-91
> URL: https://issues.apache.org/jira/browse/HDDS-91
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Components: SCM
> Reporter: Elek, Marton
> Assignee: Elek, Marton
> Priority: Major
> Fix For: 0.2.1
>
> Attachments: HDDS-91.001.patch
>
>
> In the current InProgressPool we calculate the existing replica numbers for
> all the containers based on the container reports. But we don't do anything
> in case of missing replicase.
> This patch is the initial step to process the reported data by comparing the
> reported replica numbers with the state saved in the Mapping database.
> I prerefer to do smaller patches instead of one big one, so this patch
> doesn't solve over/under replcation the problem yet just detect it.
> 1. It integrates the EventQueue with the scm and makes it available to the
> ContainerSupervisor (constructor + field changes)
> 2. In finalizeReconciliation it sends events to compare expected and current
> replicase (expected replicas are from the ContainerMapping)
> 3. Will send a new event in case of under/over replication.
> Further works are needed to react to the new events and send delete/copy
> container commands to the datanode. It also requires more information about
> the current in-progress replication: If we alread asked a new datanode to
> replicate the container we need to save it to a map to make the call
> idempotent: on the next container replication we should not request an other
> replication. I would prefer to put this additional information to the
> ContainerMapping instead of a new map.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
