I am strongly against serialization, it simply doesn't work except some
trivial cases. Explicit is better than implicit.
вт, 12 июл. 2022 г., 12:56 Ivan Daschinsky :
> Unfortunately, affinity function is not rivially constructible, at least
> default one
>
> вт, 12 июл. 2022 г., 10:37 Pavel Tupit
Unfortunately, affinity function is not rivially constructible, at least
default one
вт, 12 июл. 2022 г., 10:37 Pavel Tupitsyn :
> Alex, the second option is exactly what I've proposed above.
>
> On Tue, Jul 12, 2022 at 9:46 AM Alex Plehanov
> wrote:
>
> > Folks, why should we construct a fully
Alex, the second option is exactly what I've proposed above.
On Tue, Jul 12, 2022 at 9:46 AM Alex Plehanov
wrote:
> Folks, why should we construct a fully functional affinity function on the
> client side by custom client code? We need only a key to partition mapping,
> so only this simple mappe
Folks, why should we construct a fully functional affinity function on the
client side by custom client code? We need only a key to partition mapping,
so only this simple mapper factory will be enough.
>From my point of view there are to options possible:
- provide ability to set partition to key m
No objections to the AffinityFunctionFactory approach from my side.
I think it should be based on cacheName, not groupId.
On Mon, Jul 11, 2022 at 3:52 PM Maxim Muzafarov wrote:
> Folks,
>
> I've done research about the proposed solution and I'd like to discuss
> with you a possible options we ma
Folks,
I've done research about the proposed solution and I'd like to discuss
with you a possible options we may have. After we agreed on a solution
design I'll create a new IEP with everything we've discussed above.
So, let's consider the most completed case:
the RendezvousAffinityFunction with
Still don't understand how type id can help me to obtain valid mapper from
key to int32. Especially when we are talking about non-jvm languages.
пн, 11 июл. 2022 г., 12:33 Николай Ижиков :
> Pavel.
>
> > It is not cryptic, it is very straightforward and builds on existing
> binary type mechanism.
Pavel.
> It is not cryptic, it is very straightforward and builds on existing binary
> type mechanism.
I see the Ivan’s point here.
As I said earlier - It must be absolutely clear for user - PA works or not.
With the logic you propose it will be hiding inside Ignite machinery and logs.
> Unfor
> providing simple function Object -> int32 in cache configuration is wrong
decision
Because it is error-prone and does not work for all cases:
- You have to set it explicitly on the client for every cache.
- No way to do that if you get an existing cache by name.
> still being unable to solve th
Guys, I simply cant understand why providing simple function Object ->
int32 in cache configuration is wrong decision, but implementing cryptic
logic with class names, feature flags and still being unable to solve the
probem is ok. I don't understand how an ability to obtain a classname of
java cla
Nikolay,
> Add ability to sent custom affinity class name.
Can you please elaborate? What is sent where?
> If `partitionAwarenessEnabled=true` but custom affinity can’t be
instantiated on the client - throw an exception
Unfortunately, this is a breaking change. Currently this scenario works
witho
Hello, Pavel.
I support your proposal to transparently create custom AffinityMapper based on
server node classname, in general.
Partition Awareness crucial point for a thin client performance so It should be
absolutely clear for a user - PA works correctly or not.
So, I think, we should impleme
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 this
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 Affinity
> 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 ab
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 both
+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 t
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 `partition(
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 the
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 a
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 above.
I have no objections to extending the Thin Client configuration with a
pluggable Affinity Function.
Let's make it a normal Java setter though, system properties are hacky.
Especially when only some of the caches use custom affinity, as Maxim
mentioned.
On Wed, Jun 29, 2022 at 7:20 PM Николай Ижико
+1 to have ability to specify custom affinity for PA on thin client.
It seems to me custom affinity is a rare use-case of Ignite API.
Propose to have SystemProperty that can specify affinity implementation for a
thin client.
> 29 июня 2022 г., в 18:53, Maxim Muzafarov написал(а):
>
> Igniters
Igniters,
I've faced with a customer's cluster which has more than 150 nodes and
most for them are the thick-client nodes. Due to each thick-client is
a full-fledged cluster topology participant it affects the cluster
discovery machinery during the system operation and adding an
additional overhe
26 matches
Mail list logo
