Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
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 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 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 mapper factory by the client
>> code
>> > or
>> > - serialize custom affinity functions and custom affinity key mappers to
>> > binary objects and send it together with ClientCachePartitionResponse
>> > message. In this case, explicit client configuration or some kind of
>> client
>> > code is not required, affinity function (with type id and its internals)
>> > will be deserialized if classes are present on thin-client side and
>> will be
>> > used implicitly (for java thin client). For other thin clients (except
>> > java) type id can be retrieved from the binary object and some key to
>> > partition mapper can be provided based on this type id (for example by
>> > configured factory).
>> >
>> > пн, 11 июл. 2022 г. в 16:22, Pavel Tupitsyn :
>> >
>> > > 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 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 a custom affinity mapper
>> function
>> > is
>> > > > used.
>> > > >
>> > > >
>> > > > =
>> > > >
>> > > > The solution with sending AffintyFunction typeId.
>> > > >
>> > > > a. The deprecated AffinityKeyMapper used prior to the
>> AffinityFunction
>> > > > for calculation a key to partition mapping.
>> > > > See the link [1] - affFunction.partition(affinityKey(key))
>> > > >
>> > > > b. We are able to map typeId of the RendezvousAffinityFunction to
>> > > > another AffinityFunction on the client side to solve the mapping
>> > > > problem with any combination of AffinityFunction and
>> > > > AffinityKeyMappers ware used.
>> > > >
>> > > > c. When the cache partitions mapping request [2] is executed we are
>> > > > able to send the typeId of the RendezvousAffinityFunction back to
>> the
>> > > > client, however without sending the typeId's of custom affinity
>> > > > mappers we are not able to identify the case when a substitution of
>> > > > the AffinityFunction is required on the client side.
>> > > >
>> > > > For instance,
>> > > >
>> > > > cacheGroup_1 has RendezvousAffinityFunction + FirstAffinityKeyMapper
>> > > > cacheGroup_2 has RendezvousAffinityFunction +
>> SecondAffinityKeyMapper
>> > > >
>> > > > Adding a deprecated classes and their corresponding typeId's to the
>> > > > exchange client-server protocol sound not a good idea. However, this
>> > > > will cover all the cases.
>> > > >
>> > > > =
>> > > >
>> > > > The solution with factory method for AffintyFunction on the client
>> > side.
>> > > >
>> > > > We can also improve the solution that was proposed by me a few
>> > > > messages ago. Instead of the withPartitionAwarenessKeyMapper() [4]
>> > > > method which looks a bit weird we can add a factory method to the
>> > > > IgniteClientConfiguration that will provide a custom
>> AffinityFunction
>> > > > for caches wift `non-default` mappings.
>> > > >
>> > > > The factory may looks like:
>> > > >
>> > > > class AffinityFunctionFactory implements BiFunction> Integer,
>> > > > AffinityFunction> {
>> > > > @Override public AffinityFunction apply(Integer groupId, Integer
>> > > > parts) {
>> > > > return new RendezvousAffinityFunction(false, parts);
>> > > > }
>> > > > }
>> > > >
>> > > > This cases will have a bit straightforward implementation and
>> explicit
>> > > > AffinityFunction initialization by a user.
>> > > >
>> > > >
>> > > > WDYT?
>> > > >
>> > > >
>> > > >
>> > > > [1]
>> > > >
>> > >
>> >
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAffinityManager.java#L185
>> > > > [2]
>> > > >
>> > >
>> >
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java#L535
>> > > > [3]
>> > >
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
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 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 mapper factory by the client
> code
> > or
> > - serialize custom affinity functions and custom affinity key mappers to
> > binary objects and send it together with ClientCachePartitionResponse
> > message. In this case, explicit client configuration or some kind of
> client
> > code is not required, affinity function (with type id and its internals)
> > will be deserialized if classes are present on thin-client side and will
> be
> > used implicitly (for java thin client). For other thin clients (except
> > java) type id can be retrieved from the binary object and some key to
> > partition mapper can be provided based on this type id (for example by
> > configured factory).
> >
> > пн, 11 июл. 2022 г. в 16:22, Pavel Tupitsyn :
> >
> > > 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 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 a custom affinity mapper function
> > is
> > > > used.
> > > >
> > > >
> > > > =
> > > >
> > > > The solution with sending AffintyFunction typeId.
> > > >
> > > > a. The deprecated AffinityKeyMapper used prior to the
> AffinityFunction
> > > > for calculation a key to partition mapping.
> > > > See the link [1] - affFunction.partition(affinityKey(key))
> > > >
> > > > b. We are able to map typeId of the RendezvousAffinityFunction to
> > > > another AffinityFunction on the client side to solve the mapping
> > > > problem with any combination of AffinityFunction and
> > > > AffinityKeyMappers ware used.
> > > >
> > > > c. When the cache partitions mapping request [2] is executed we are
> > > > able to send the typeId of the RendezvousAffinityFunction back to the
> > > > client, however without sending the typeId's of custom affinity
> > > > mappers we are not able to identify the case when a substitution of
> > > > the AffinityFunction is required on the client side.
> > > >
> > > > For instance,
> > > >
> > > > cacheGroup_1 has RendezvousAffinityFunction + FirstAffinityKeyMapper
> > > > cacheGroup_2 has RendezvousAffinityFunction + SecondAffinityKeyMapper
> > > >
> > > > Adding a deprecated classes and their corresponding typeId's to the
> > > > exchange client-server protocol sound not a good idea. However, this
> > > > will cover all the cases.
> > > >
> > > > =
> > > >
> > > > The solution with factory method for AffintyFunction on the client
> > side.
> > > >
> > > > We can also improve the solution that was proposed by me a few
> > > > messages ago. Instead of the withPartitionAwarenessKeyMapper() [4]
> > > > method which looks a bit weird we can add a factory method to the
> > > > IgniteClientConfiguration that will provide a custom AffinityFunction
> > > > for caches wift `non-default` mappings.
> > > >
> > > > The factory may looks like:
> > > >
> > > > class AffinityFunctionFactory implements BiFunction > > > AffinityFunction> {
> > > > @Override public AffinityFunction apply(Integer groupId, Integer
> > > > parts) {
> > > > return new RendezvousAffinityFunction(false, parts);
> > > > }
> > > > }
> > > >
> > > > This cases will have a bit straightforward implementation and
> explicit
> > > > AffinityFunction initialization by a user.
> > > >
> > > >
> > > > WDYT?
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAffinityManager.java#L185
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java#L535
> > > > [3]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/AffinityFunction.java#L53
> > > > [4]
> > > >
> > >
> >
> https://github.com/apache/ignite/pull/10140/files#diff-fb60155466fa2c31d6d1270c0e08f15f1ad9c1a2272fc9bb137c07d9ae5c1b98R47
> > > >
> > > > On
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
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 mapper factory will be enough.
> From my point of view there are to options possible:
> - provide ability to set partition to key mapper factory by the client code
> or
> - serialize custom affinity functions and custom affinity key mappers to
> binary objects and send it together with ClientCachePartitionResponse
> message. In this case, explicit client configuration or some kind of client
> code is not required, affinity function (with type id and its internals)
> will be deserialized if classes are present on thin-client side and will be
> used implicitly (for java thin client). For other thin clients (except
> java) type id can be retrieved from the binary object and some key to
> partition mapper can be provided based on this type id (for example by
> configured factory).
>
> пн, 11 июл. 2022 г. в 16:22, Pavel Tupitsyn :
>
> > 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 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 a custom affinity mapper function
> is
> > > used.
> > >
> > >
> > > =
> > >
> > > The solution with sending AffintyFunction typeId.
> > >
> > > a. The deprecated AffinityKeyMapper used prior to the AffinityFunction
> > > for calculation a key to partition mapping.
> > > See the link [1] - affFunction.partition(affinityKey(key))
> > >
> > > b. We are able to map typeId of the RendezvousAffinityFunction to
> > > another AffinityFunction on the client side to solve the mapping
> > > problem with any combination of AffinityFunction and
> > > AffinityKeyMappers ware used.
> > >
> > > c. When the cache partitions mapping request [2] is executed we are
> > > able to send the typeId of the RendezvousAffinityFunction back to the
> > > client, however without sending the typeId's of custom affinity
> > > mappers we are not able to identify the case when a substitution of
> > > the AffinityFunction is required on the client side.
> > >
> > > For instance,
> > >
> > > cacheGroup_1 has RendezvousAffinityFunction + FirstAffinityKeyMapper
> > > cacheGroup_2 has RendezvousAffinityFunction + SecondAffinityKeyMapper
> > >
> > > Adding a deprecated classes and their corresponding typeId's to the
> > > exchange client-server protocol sound not a good idea. However, this
> > > will cover all the cases.
> > >
> > > =
> > >
> > > The solution with factory method for AffintyFunction on the client
> side.
> > >
> > > We can also improve the solution that was proposed by me a few
> > > messages ago. Instead of the withPartitionAwarenessKeyMapper() [4]
> > > method which looks a bit weird we can add a factory method to the
> > > IgniteClientConfiguration that will provide a custom AffinityFunction
> > > for caches wift `non-default` mappings.
> > >
> > > The factory may looks like:
> > >
> > > class AffinityFunctionFactory implements BiFunction > > AffinityFunction> {
> > > @Override public AffinityFunction apply(Integer groupId, Integer
> > > parts) {
> > > return new RendezvousAffinityFunction(false, parts);
> > > }
> > > }
> > >
> > > This cases will have a bit straightforward implementation and explicit
> > > AffinityFunction initialization by a user.
> > >
> > >
> > > WDYT?
> > >
> > >
> > >
> > > [1]
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAffinityManager.java#L185
> > > [2]
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java#L535
> > > [3]
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/AffinityFunction.java#L53
> > > [4]
> > >
> >
> https://github.com/apache/ignite/pull/10140/files#diff-fb60155466fa2c31d6d1270c0e08f15f1ad9c1a2272fc9bb137c07d9ae5c1b98R47
> > >
> > > On Mon, 11 Jul 2022 at 13:14, Ivan Daschinsky
> > wrote:
> > > >
> > > > 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
Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients
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 mapper factory by the client code
or
- serialize custom affinity functions and custom affinity key mappers to
binary objects and send it together with ClientCachePartitionResponse
message. In this case, explicit client configuration or some kind of client
code is not required, affinity function (with type id and its internals)
will be deserialized if classes are present on thin-client side and will be
used implicitly (for java thin client). For other thin clients (except
java) type id can be retrieved from the binary object and some key to
partition mapper can be provided based on this type id (for example by
configured factory).
пн, 11 июл. 2022 г. в 16:22, Pavel Tupitsyn :
> 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 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 a custom affinity mapper function is
> > used.
> >
> >
> > =
> >
> > The solution with sending AffintyFunction typeId.
> >
> > a. The deprecated AffinityKeyMapper used prior to the AffinityFunction
> > for calculation a key to partition mapping.
> > See the link [1] - affFunction.partition(affinityKey(key))
> >
> > b. We are able to map typeId of the RendezvousAffinityFunction to
> > another AffinityFunction on the client side to solve the mapping
> > problem with any combination of AffinityFunction and
> > AffinityKeyMappers ware used.
> >
> > c. When the cache partitions mapping request [2] is executed we are
> > able to send the typeId of the RendezvousAffinityFunction back to the
> > client, however without sending the typeId's of custom affinity
> > mappers we are not able to identify the case when a substitution of
> > the AffinityFunction is required on the client side.
> >
> > For instance,
> >
> > cacheGroup_1 has RendezvousAffinityFunction + FirstAffinityKeyMapper
> > cacheGroup_2 has RendezvousAffinityFunction + SecondAffinityKeyMapper
> >
> > Adding a deprecated classes and their corresponding typeId's to the
> > exchange client-server protocol sound not a good idea. However, this
> > will cover all the cases.
> >
> > =
> >
> > The solution with factory method for AffintyFunction on the client side.
> >
> > We can also improve the solution that was proposed by me a few
> > messages ago. Instead of the withPartitionAwarenessKeyMapper() [4]
> > method which looks a bit weird we can add a factory method to the
> > IgniteClientConfiguration that will provide a custom AffinityFunction
> > for caches wift `non-default` mappings.
> >
> > The factory may looks like:
> >
> > class AffinityFunctionFactory implements BiFunction > AffinityFunction> {
> > @Override public AffinityFunction apply(Integer groupId, Integer
> > parts) {
> > return new RendezvousAffinityFunction(false, parts);
> > }
> > }
> >
> > This cases will have a bit straightforward implementation and explicit
> > AffinityFunction initialization by a user.
> >
> >
> > WDYT?
> >
> >
> >
> > [1]
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAffinityManager.java#L185
> > [2]
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java#L535
> > [3]
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/AffinityFunction.java#L53
> > [4]
> >
> https://github.com/apache/ignite/pull/10140/files#diff-fb60155466fa2c31d6d1270c0e08f15f1ad9c1a2272fc9bb137c07d9ae5c1b98R47
> >
> > On Mon, 11 Jul 2022 at 13:14, Ivan Daschinsky
> wrote:
> > >
> > > 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.
> > > >
> > > > 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.
> > > >
> > > > > Unfortunately, this is a breaking change.
