ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Replacing NodeFilter functionality with label approach
Date Thu, 01 Aug 2019 16:33:53 GMT

I think this is a good idea. We already had problems with ClusterGroups
that won't recompute until PME, or which become invalid after PME. Relying
on string labels would fix all that.

I can think of a node filter which can't be replaced with label filter
(e.g. the one checking for presence of some partition) but generally that's
a Bad Idea.

Ilya Kasnacheev

чт, 1 авг. 2019 г. в 18:47, Pavel Kovalenko <jokserfn@gmail.com>:

> Hello Igniters,
> I would like to start a discussion about simplifying NodeFilter
> functionality.
> At the moment NodeFilter's are used to control Caches and Services
> distribution across nodes.
> In most cases, NodeFIlter implementation seeks for a specific attribute in
> NodeAttributes map. If the attribute is found on a node, Cache or Service
> is deployed on that node.
> However, current NodeFilter interface gives a user much more ways to adjust
> such distribution. This gives more flexibility for configuration on the one
> hand but it increases complexity and understanding of the API.
> Because NodeFilter is a functional interface and configured on the user
> side there are problems with serialization, class loading and consistency
> check of such objects.
> Here is a couple of problems we have with NodeFilter:
> 1. User-defined node filter classes must be deployed on all nodes whether
> or nor they required on them. This increases the complexity of resolving
> problems like in IGNITE-1903.
> 2. Part of consistency checking of CacheConfigurations based on NodeFilter
> classes comparison, not on objects. User may use the same class for
> NodeFilter but with different constructor parameters and this can lead to
> inconsistent behavior of the same node filter on different nodes while
> consistency check will pass.
> 3. We can resolve p.2 using objects equality approach, but we can't force
> users to properly implement .equals() method on NodeFilter class. We can
> only recommend doing that thing. If the user forgot to implement .equals()
> or did it incorrectly we can't deal anything with it.
> All of those problems can lead to cluster instability and unpredictable
> behavior.
> Instead of continuing using NodeFilter we can give more safe and simpler
> way to implement the same feature. I propose the following approach that is
> used in many other distributed systems:
> User may tag every Ignite node configuration with a specific label that
> will be placed in NodeAttributes map.
> NodeFilter interface replaced with just a string label. If a node
> NodeAttributes map contains such label a Cache or Service will be deployed
> on that node and not deployed if the label doesn't exist.
> I would like to add this change to Ignite 3.0 scope because it's an
> important and major change in public API.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message