ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksandr Shapkin <lexw...@gmail.com>
Subject NodeFilter discussion
Date Tue, 14 Jul 2020 09:48:20 GMT

I'm working on adding the NodeFilter functionality to the .NET client

And there are several points I want to highlight regarding the current

1) A node filter is being called on every put which seems redundant. This
might be ok unless we don't cross the JNI boundaries. For .NET, it means at
least an additional serialization on every cache operation.
Can we change this behavior and call CU.affinityNode(node, aff.cacheFilter)
only once per assignment? Or at least to wrap it with some cacheable

2) It feels like the default AttributeNodeFilter is suitable for most of
the cases. I found an existing proposal of removing custom filters, but the
thread seems to be abandoned:

Do we need to support those filters?

3) I noticed that in reality a filter is limited to the DetachedClusterNode
representation. Consider the following stack trace and the #

 at org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1332)
	  at org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:329)
	  at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.recalculateBaselineAssignment(GridAffinityAssignmentCache.java:461)

Thus, any NodeFilter depending on a ClusterNode#addresses
or ClusterNode#metrics will fail due to "Operation is not supported on

Therefore if we disallow custom node filters completely, the latter issue
would be resolved as well.

Am I missing something?


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