Hi, I'm working on adding the NodeFilter functionality to the .NET client https://issues.apache.org/jira/browse/IGNITE-2890
And there are several points I want to highlight regarding the current implementation: 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 function? 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: http://apache-ignite-developers.2346864.n4.nabble.com/Replacing-NodeFilter-functionality-with-label-approach-td42874.html#a42942 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 # createBaselineView 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 DetachedClusterNode". Therefore if we disallow custom node filters completely, the latter issue would be resolved as well. Am I missing something? -- Alex.
