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 <nizhi...@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 <nizhi...@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,
> > >
> > >
> > >
signature.asc
Description: This is a digitally signed message part
