[
https://issues.apache.org/jira/browse/HDDS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482811#comment-16482811
]
Anu Engineer commented on HDDS-91:
----------------------------------
[~elek] Thanks for the patch. I think this patch will change a little bit as we
work forward towards the Event based SCM.
# The class {{DN2ContainerMap}} has a function called {{processReport}} that
function will the mismatched Containers. That is it will return the missing
containers and new containers in the ResultSet.
# We should take those lists and update the container State Map, perhaps using
event queue or directly.
# Then we need to update the DN2ContainerMap
# Then we can post messages to various other participants in SCM. Let us chat
about this sometime to get more clarity into this.
> 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]