ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Replacing NodeFilter functionality with label approach
Date Mon, 05 Aug 2019 14:59:08 GMT
Pavel.

> I don't see yet any practical cases with NodeFilter that can't be resolved
> using just labels.

Filters based of hostname or ip address.

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

I don't think we should take "hard to implement" as an argument in this discussion :)
Seems, whole Ignite peer class loading design need to be improved.

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

This is common issue to every user-provided code.
Wrong implementation of affininty function is one the examples that comes in the mind.

I think flexibility is good thing, so I'm -1 to reduce it.

What do you think?

В Пн, 05/08/2019 в 17:35 +0300, Pavel Kovalenko пишет:
> Nikolay,
> 
> Thank you for your feedback.
> Could you please tell more about cases when custom node filter that not
> relies on node attributes may be used?
> For me, it's flexibility just for flexibility that introduces problems
> described in the topic.
> I don't see yet any practical cases with NodeFilter that can't be resolved
> using just labels.
> 
> 
> 
> пн, 5 авг. 2019 г. в 16:28, Nikolay Izhikov <nizhikov@apache.org>:
> 
> > Ivan,
> > 
> > ~Mail~ Talks are cheap! Show me the code (C) :)
> > 
> > 
> > class NodeAttributeFilter<T> implements IgnitePredicate<ClusterNode>
{
> >         private String name;
> >         private T value;
> > 
> > 
> >         public boolean apply(ClusterNode n) {
> >                 return Objects.equals(n.attribute(name), value);
> >         }
> > 
> >         //...setters, getters.
> > }
> > 
> > 
> > В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> > > Hi Nikolay,
> > > 
> > > Could you please elaborate how will NodeAttributeFilter behave? Do you
> > > mean specifying attribute name and value for exact comparison inside?
> > > Without any dynamic (user) code involved?
> > > 
> > > Also I it is quite interesting for me what flexibility you are
> > > thinking about? I think that the topic is quite important and it would
> > > be great to collect use cases and describe best practices in
> > > documentation.
> > > 
> > > пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov <nizhikov@apache.org>:
> > > > 
> > > > Hello, Pavel.
> > > > 
> > > > I think we shouldn't reduce flexibility of NodeFilter.
> > > > So, I am -1 to remove it in Ignite 3.
> > > > 
> > > > Instead, Ignite can provide NodeAttributeFilter implementation of
> > 
> > NodeFilter.
> > > > Seems, it will resolve all described issues.
> > > > 
> > > > 
> > > > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > > > Hello!
> > > > > 
> > > > > 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.
> > > > > 
> > > > > Regards,
> > > 
> > > 
> > > 

Mime
View raw message