ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Kovalenko <jokse...@gmail.com>
Subject Replacing NodeFilter functionality with label approach
Date Thu, 01 Aug 2019 15:47:02 GMT
Hello Igniters,

I would like to start a discussion about simplifying NodeFilter
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

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