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

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