You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Marton Elek (Jira)" <ji...@apache.org> on 2020/04/28 11:53:00 UTC

[jira] [Resolved] (HDDS-3315) Use EventQueue for delayed/immediate safe mode rule notification

     [ https://issues.apache.org/jira/browse/HDDS-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marton Elek resolved HDDS-3315.
-------------------------------
    Fix Version/s: 0.6.0
       Resolution: Fixed

> Use EventQueue for delayed/immediate safe mode rule notification
> ----------------------------------------------------------------
>
>                 Key: HDDS-3315
>                 URL: https://issues.apache.org/jira/browse/HDDS-3315
>             Project: Hadoop Distributed Data Store
>          Issue Type: Improvement
>          Components: SCM
>            Reporter: Marton Elek
>            Assignee: Marton Elek
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 0.6.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> SCM is built from loosely coupled components which communicate with async event with each other.
> Using the same abstraction (EventQueue) has the benefit that we can use the same visibility / testing tools such as the 'ozone insight' definition (which makes visible all the messages) or the test handler (which can wait until all the event queue messages are processed) 
> During the review of HDDS-3221 it was suggested (by me) to use the EventQueue instead of the new SafeModeNotification interface. 
> There was only one counter argument against it:
> bq. I personally find the event queue logic hard to follow due to its async nature (you cannot just follow method calls in the IDE). Its not bad, but more difficult when you don't yet understand it, while registering some instances to be notified is easy to follow in an IDE. This is of course a subjective opinion :)
> I respect this opinion, but I think it's better to use one abstraction and a consistent architecture inside one component (together with all the existing limitations). The EventQueue is not the only one possible solution, but an existing one. We can either design and switch to a new one or use the existing one.
> In this patch I would like to show how the previous listener interface can be replaced by the EventQueue.
> It (hopefully) shows that this is not complex, and in fact can help us to decouple different component from each other    



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org