[
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: [email protected]
For additional commands, e-mail: [email protected]
