To clarify: you can use a different AffinityFunction implementation on the
client side. It just has to map to the same binary typeId.
Even if there is a legacy setup with AffinityKeyMapper on servers, you can
craft an AffinityFunction for the client that achieves correct behavior.
So I believe
AffinityKeyMapper is just a subset of AffinityFunction, isn't it?
So by supporting AffinityFunction we cover all AffinityKeyMapper use cases.
> managing the classpath, a user should always keep in mind it
I don't consider this a problem. This is how Java works, what can we do?
You can also stick
Pavel,
Yes, you're right that AffinityKeyMapper is deprecated, this is sad to
say but it still used.
Let me describe the cases in more detail. In general, we have
customers which are using:
1. an own custom AffinityFunction;
2. the default RendezvousAffinityFunction + an own deprecated
> AffinityKeyMapper (it will be required too)
It is deprecated. We should not add any functionality on top of deprecated
stuff.
Let's discuss only AffinityFunction.
> this approach requires of these classes to be present on a thin client
side and it can be tricky
Any of the approaches discussed
Folks,
I'd like also to mention since we are talking about a customer's
custom affinity function and affinity mapper implementations we could
face with some issues during these classes instantiation. It could
work for the customer which I've faced on, but I cannoun be sure that
this approach will
Folks,
I'm not familiar with a thin client protocol, so, please, correct me
if I'm wrong - is it possible sending classes over the network for
different type of thin clients? It seems to me it will not work. I
think it is possible to use class name/or type id and we are capable
to instantiate
+1 to Pavel’s approach. Giving user the ability to set affinity function that
is potentially different from the one that is on server doesn’t look good.
I’d even go further and try sending the affinity function class itself over the
network, so users won’t have to alter the classpath by adding
Can we actually avoid any public API changes and do the following:
When a feature flag is present and there is a custom affinity function on
the server, send back the class name (or binary type id, if possible) of
the affinity function?
Then simply instantiate it on the client and call
Pavel,
Here is my thoughts.
As I mentioned before, we will need only the
AffinityFunction#partition(Object key) method for calculation on the
client side due to all the partition-to-node mappings will be
requested asynchronously from a server node how it is happening now
for cache groups with
Maxim,
I am confused. We were talking about a custom Affinity Function.
As you noted, AffinityKeyMapper is deprecated, why do we add something
named "setPartitionAwarenessKeyMapper"?
Internal API approach is hacky.
IMO we should either develop a proper feature with a good public API, or
not add
Folks,
Thank you for your comments.
First of all, I'd like to point out that if the cache is created with
a custom affinity function or the legacy AffinityKeyMapper interface,
the thin client should be able to provide only a `key-to-partition`
mapping function to handle the case described
Hello,
I've updated IEP [1] and prepared a patch for Java services [2].
I'm going to merge it soon and continue working on the .NET service
interceptor [3].
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119
[2] https://github.com/apache/ignite/pull/10128
[3]
+1, seems like a good idea
On Thu, Jul 7, 2022 at 4:10 PM Stephen Darlington <
stephen.darling...@gridgain.com> wrote:
> I’ve been thinking about the “first run” experience and some of the
> defaults we have.
>
> For example, I can start a thick client entirely with the defaults:
>
> var cfg =
I’ve been thinking about the “first run” experience and some of the defaults we
have.
For example, I can start a thick client entirely with the defaults:
var cfg = new IgniteConfiguration();
var ignite = Ignition.start(cfg);
But the same does not work for the thin client:
var cfg = new
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New test failure in master
IgniteCacheQueryStopOnCancelOrTimeoutDistributedJoinSelfTest.testCancel2
15 matches
Mail list logo
