Nikolay,
> Filters based of hostname or ip address.
Hostname or IP address can be injected to Ignite configuration as labels
(NodeAttributes) without dynamic lookup necessary.
> 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.
I think that code simplification, reducing the complexity of future support
and reducing number of possible bugs can be arguments :)
> This is common issue to every user-provided code.
> Wrong implementation of affininty function is one the examples that comes
in the mind.
But it doesn't mean that we should do nothing with it. As fewer, we have
possibilities of injecting user-provided code without strict necessary, as
the more durable and predictable product we have as a result.
WDYT?
пн, 5 авг. 2019 г. в 17:56, Nikolay Izhikov <nizhi...@apache.org>:
> 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,
> > > >
> > > >
> > > >
>
