ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryker Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-11676) Clean up custom event callbacks
Date Fri, 19 Apr 2019 10:03:00 GMT

    [ 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
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

View raw message