[
https://issues.apache.org/jira/browse/IGNITE-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-1401.
-------------------------------------
Resolution: Won't Fix
I doubt we need this feature at the moment. Local node join is of no use, since
Ignition.start() is synchronous operation, and once control is returned to the
user, he may consider node joined. If node is dropped from topology, it will
never come back, this is already handled by segmentation mechanics and
EVT_NODE_SEGMENTED event. And for client nodes, which could disconnect and then
reconnect, we already have EVT_CLIENT_NODE_DISCONNECTED and
EVT_CLIENT_NODE_RECONNECTED events.
> Introduce special local node discovery events
> ---------------------------------------------
>
> Key: IGNITE-1401
> URL: https://issues.apache.org/jira/browse/IGNITE-1401
> Project: Ignite
> Issue Type: Improvement
> Components: general
> Reporter: Andrey Kornev
> Priority: Minor
> Labels: easyfix
>
> Currently, Ignite doesn't record the EVT_NODE_JOINED event for the local
> node. In general, it might be useful to know when the local node has joined
> the cluster as well as when the local node has left the cluster (or has
> failed to join).
> I'd like to propose to introduce a couple of new Ignite events:
> EVT_LOCAL_NODE_JOINED and EVT_LOCAL_NODE_LEFT that will be generated by the
> Discovery Manager when it has successfully started and when it has
> disconnected correspondingly. Importantly, the events must be generated by
> the discovery worker thread (and only this thread!) so that the total
> ordering of all discovery events is preserved. Clearly, the
> EVT_LOCAL_NODE_LEFT event should be generated and delivered on the
> best-effort basis.
> EVT_LOCAL_NODE_FAILED may also be considered: it could be generated when the
> cluster coordinator has refused the node's attempt to join the cluster (for
> whatever reason).
> The introduction of local node-specific discovery events rather than reusing
> the existing ones would help keep the existing code backward compatible, and
> in general makes sense.
> It is possible to approximate this feature using just the existing API, but
> the code is complex, prone to race conditions and may require use of Ignite
> internal APIs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)