Hello Pavel,
I think your suggestion is better because it seems more flexible to me
and only one method needs to be implemented by the user. So we don't
need a default (no-op) implementation.
But with this approach, a service can only have one interceptor, right?
It also seems to be more error pro
Hello,
The single method proposal looks good to me.
> But with this approach, a service can only have one interceptor, right?
Pavel, I think we can delegate interceptors as a chain. The last
delegate calls the service method. In this way, multiple ordered
interceptors can be configured.
ср, 29
> we can delegate interceptors as a chain
Thanks Nikita, this was my thinking too.
On Wed, Jun 29, 2022 at 1:55 PM Nikita Amelchev
wrote:
> Hello,
>
> The single method proposal looks good to me.
>
> > But with this approach, a service can only have one interceptor, right?
>
> Pavel, I think we
We can rename "Supplier delegate" to "next", like in ASP.NET Core
Middleware.
So it is clear that there is a chain of calls.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/write?view=aspnetcore-6.0#middleware-class
On Wed, Jun 29, 2022 at 2:08 PM Pavel Tupitsyn wrote:
> >
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
+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
