Igniters,
I'd like to have an open discussion about this IEP in relation to the name
of the parameter that activates the feature:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Presently selected term ("affinityAwareness") is not accurate and will
cause a lot of confusion. (sorry not starting this discussion earlier, I
came across the method name recently).
The goal of the improvement was to make our thin clients *aware of the
partitions' distribution* so that requests can be directed straight to the
nodes that keep a copy of the data avoiding the proxy node. Thick clients
are partition-aware by nature and get a partitions distribution map with
the help of the partition-map exchange process. So, partitioning/sharding
are coined terms among distributed systems and the purpose is understood.
Partitioning and partition-awareness are linked together logically. With
this feature in place, our thin clients become partition-aware as well as
the thick ones (even though there are still some limitations and
implementation differences).
Now, for some reason and keeping the goal of the IEP in mind (make the thin
clients aware of the distribution of the partitions), we named the
parameter that activates this capability as "affinityAwareness" and that
puzzled me a lot as long as "affinity" capabilities of Ignite are
understood by users and communicated differently. Affinity implies
*relations.* That's a relation between data sets stored in the cluster
(account and transactions, device and temperature reported by it, etc.) and
the relationship is established with the help of affinity keys in order to
avoid data shuffling over the network for various operations.
So, the proposal, before this improvement goes mainstream let's rename
"affinityAwareness" to *"partitionAwareness"* for the public APIs. Let's
not complicate the lifes of application developers (there are already many
improperly named methods in the API), don't complicate the life of those
who explain and introduce Ignite to the developer audience.
Thoughts? We have briefly discussed this with Pavel and Igor and see no
major obstacles for the renaming on the .NET, Python, C++, Node.JS clients
end. However, the same needs to be done for the Java side as well.
-
Denis
