You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ryker Zhang (JIRA)" <ji...@apache.org> on 2019/04/19 10:03:00 UTC

[jira] [Commented] (IGNITE-11676) Clean up custom event callbacks

    [ https://issues.apache.org/jira/browse/IGNITE-11676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821818#comment-16821818 ] 

Ryker Zhang commented on IGNITE-11676:
--------------------------------------

Hi [~agoncharuk],

How about adding method to DiscoveryCustomMessage? Like
{code:java}
public boolean needIncMinorTopVer(GridDiscoveryManager mgr, AffinityTopologyVersion topVer, ClusterNode node);{code}
I found customMsgs could have several CustomEventListeners. If we add method to CustomEventListener, we may repeat version logic when add new CustomEventListener to same customMsg, and minorTopVer need increment once in the procedure. In addition, some customMsgs (like ChangeGlobalStateFinishMessage) don't have any CustomEventListener.
If we add method to DiscoveryCustomMessage and move logic to corresponding customMsg, GridDiscoveryMananger can use customMsg.needIncMinorTopVer() to determine whether increment minor topology versionĀ at line 671.
Am I missing something? Any suggestions?

> Clean up custom event callbacks
> -------------------------------
>
>                 Key: IGNITE-11676
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11676
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexey Goncharuk
>            Assignee: Ryker Zhang
>            Priority: Major
>
> Currently, {{GridDiscoveryManager}} has several ways of notifying Ignite components of discovery events:
>  * Line 668: a set of {{instanceof}} statements to invoke specific callbacks for components (for example, {{ctx.state().onStateChangeMessage(...)}}, {{ctx.cache().onCustomEvent(...)}}
>  * Later, on line 715: we call a somewhat generic custom event listeners
>  * Finally, on line 876, if the custom message was of a specific type, we fire EVT_DISCOVERY_CUSTOM_EVT
> Overall, this is a huge abstraction leak, and all non-discovery specifics should be eliminated from {{GridDiscoveryManager}}. I suggest the following:
> 1) Change {{CustomEventListener}} to have two methods: one of them should return {{true}} or {{false}} to determine whether the minor topology version should be incremented
> 2) Move all logic to corresponding components
> 3) Get rid of code on line 876, I see no need in this. Also, consider removing {{EVT_DISCOVERY_CUSTOM_EVT}}, as this is private API and should now be covered by the specific listener



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)