> and it fully switches to annotation-based injection.
+1 to do it.
> 19 окт. 2021 г., в 22:14, Valentin Kulichenko <valentin.kuliche...@gmail.com>
> написал(а):
>
> That's actually a good point. In Java, we can do the following:
> 1. Add init/execute/cancel methods without parameters.
> 2. Add default no-op implementations for the new methods (this is required
> to preserve compatibility).
> 3. For old methods that take ServiceContext as a parameter, add default
> implementations that delegate to new methods.
> 4. Deprecate the old methods on the API.
> 5. On the implementation level, still use the old methods (again - for
> compatibility).
> 6. Finally, add a @ServiceContextResource annotation to inject
> ServiceContext.
>
> If I haven't missed anything, this is not a breaking change, and it fully
> switches to annotation-based injection.
>
> I'm not sure this is possible in .NET though.
>
> -Val
>
> On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin <xxt...@gmail.com> wrote:
>
>>> Removing parameters from a public interface method is a breaking change,
>>> or do you mean something else?
>>
>> Sorry, I meant that we can inject the service context, but leave it
>> available in the init/execute/cancel methods and add a default "no-op"
>> implementation in the interface for them. Can we do this?
>>
>>> Regarding .NET - let's have a separate ticket for that?
>> If we decide to "inject" a service context - this should be done in a
>> separate ticket.
>> If you are talking about "proxy service context" - I can split it into
>> 3 parts (java, Net, and thin clients)
>>
>> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn <ptupit...@apache.org>:
>>>
>>> Pavel,
>>>
>>>> From my point of view, this should not break anything
>>> Removing parameters from a public interface method is a breaking change,
>>> or do you mean something else?
>>>
>>> Regarding .NET - let's have a separate ticket for that?
>>> We can discuss and implement Java changes first.
>>>
>>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin <xxt...@gmail.com>
>> wrote:
>>>
>>>> Thanks a lot for your suggestions.
>>>>
>>>>> We might consider injecting the ServiceContext instead of passing it
>> to
>>>>> IgniteService methods, but I believe this will be a breaking change?
>>>>
>>>> From my point of view, this should not break anything. We can inject a
>>>> service context when initializing a service and keep it accessible in
>>>> state transition methods (init/execute/cancel).
>>>> Currently, in .Net ServiceContext doesn't share the same instance, but
>>>> this can be reworked - for example, we can store the service context
>>>> (with a reference to the service) in the resource registry instead of
>>>> the service itself.
>>>>
>>>> But I don't see much usability improvement with such a feature if the
>>>> user still needs to implement state transition methods. I think it
>>>> would be nice to add default "no-op" implementations for them.
>>>> Unfortunately, we are currently unable to do the same in .Net because
>>>> such a feature is not supported in C# 4.0 (it's available in C# 8.0).
>>>>
>>>> Can we add default "no-op" implementations for init/execute/cancel
>>>> methods in Java and leave them unchanged in .Net?
>>>>
>>>> вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko
>>>> <valentin.kuliche...@gmail.com>:
>>>>>
>>>>> I support #2, because we already have the ServiceContext. Having
>>>>> both ServiceContext and @ServiceRequestContextResource that injects
>> some
>>>>> function (or any other mechanism for that matter) will be VERY
>> confusing.
>>>>> Let's keep it simple.
>>>>>
>>>>> At the same time, I do agree with Nikolay that injection is the
>> approach
>>>>> taken across the platform, so I'm not sure why we are not using it
>> here.
>>>> We
>>>>> might consider injecting the ServiceContext instead of passing it to
>>>>> IgniteService methods, but I believe this will be a breaking change?
>>>>>
>>>>> -Val
>>>>>
>>>>> On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky <ivanda...@gmail.com
>>>
>>>> wrote:
>>>>>
>>>>>> I am for limiting types of attributes values only to UTF-8 strings
>> and
>>>>>> bytearrays.
>>>>>> Also, I agree with Pavel, (2) is clear and without any reflection.
>>>>>>
>>>>>> вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov <nizhi...@apache.org
>>> :
>>>>>>
>>>>>>> I like (1) options.
>>>>>>>
>>>>>>> @ServiceRequestContextResource
>>>>>>> private Function<String, Object> ctxFunc;
>>>>>>>
>>>>>>> Because, we use this style of API for injection of other
>> resources -
>>>>>>> logger, ignite instance, etc.
>>>>>>> It may be confusing for the user to use several API styles for
>>>> solving
>>>>>>> similar tasks.
>>>>>>>
>>>>>>>
>>>>>>>> 19 окт. 2021 г., в 11:04, Pavel Tupitsyn <ptupit...@apache.org
>>>
>>>>>>> написал(а):
>>>>>>>>
>>>>>>>> (2) seems to be the cleanest and most discoverable to me,
>>>>>>>> also simpler to implement (no reflection necessary).
>>>>>>>>
>>>>>>>> But existing ServiceContext properties are for the entire
>>>> instance, not
>>>>>>> for
>>>>>>>> the current call.
>>>>>>>> So, to make it clear and obvious, let's do
>>>>>>>> ServiceContext.currentCallContext().attribute(...).
>>>>>>>>
>>>>>>>> On Mon, Oct 18, 2021 at 7:20 PM Pavel Pereslegin <
>> xxt...@gmail.com
>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> I agree with Ivan that we can improve the user experience in
>>>> Ignite
>>>>>>>>> services by adding support for "middleware".
>>>>>>>>> And as a first step, we need to pass the "caller context" to
>> the
>>>>>>> service.
>>>>>>>>>
>>>>>>>>> I see the following API options for reading this "context"
>> inside
>>>> a
>>>>>>>>> service:
>>>>>>>>> (please see "API proposal" section in Jira [1] for full
>> formatted
>>>>>>> examples)
>>>>>>>>>
>>>>>>>>> 1. Using a custom annotation (ServiceRequestContextResource)
>> and
>>>>>>>>> reading context attributes with a function.
>>>>>>>>>
>>>>>>>>> @ServiceRequestContextResource
>>>>>>>>> private Function<String, Object> ctxFunc;
>>>>>>>>>
>>>>>>>>> public void serviceMethod() {
>>>>>>>>> String login = (String)ctxFunc.apply("login");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> 2. Using a new method of the existing ServiceContext.
>>>>>>>>>
>>>>>>>>> private ServiceContext svcCtx;
>>>>>>>>>
>>>>>>>>> public void init(ServiceContext svcCtx) {
>>>>>>>>> this.svcCtx = svcCtx;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public void serviceMethod() {
>>>>>>>>> String login = svcCtx.attribute("login");
>>>>>>>>> // and/or
>>>>>>>>> String login =
>> (String)svcCtx.attributes().get("login");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The next two options require wrapping Map<String, Object>
>> into a
>>>> new
>>>>>>>>> ServiceRequestContext class.
>>>>>>>>>
>>>>>>>>> 3. Read context "wrapper" using special annotation and
>> supplier.
>>>>>>>>>
>>>>>>>>> @ServiceRequestContextResource
>>>>>>>>> private Supplier<ServiceRequestContext> ctxSupplier;
>>>>>>>>>
>>>>>>>>> public void serviceMethod() {
>>>>>>>>> String login = ctxSupplier.get().attribute("login");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> 4. Using the special static method of the "wrapper" class.
>>>>>>>>>
>>>>>>>>> public void serviceMethod() {
>>>>>>>>> String login =
>>>>>>> ServiceRequestContext.current().attribute("login");
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Let's discuss which one is the way to go.
>>>>>>>>>
>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15572
>>>>>>>>>
>>>>>>>>> вт, 12 окт. 2021 г. в 13:51, Ivan Daschinsky <
>> ivanda...@gmail.com
>>>>> :
>>>>>>>>>>
>>>>>>>>>> Hi, Val
>>>>>>>>>>
>>>>>>>>>>>> The examples you mentioned are more related to internal
>>>> activities
>>>>>>>>> (e.g.,
>>>>>>>>>>>> if authentication is handled by an Ignite server node, it
>> can
>>>>>> create
>>>>>>>>> its
>>>>>>>>>>>> internal context for a connection - this is certainly
>>>> reasonable).
>>>>>>> I'm
>>>>>>>>>> only
>>>>>>>>>>>> worried about exposing this to the end user.
>>>>>>>>>>
>>>>>>>>>> I'm talking about not Ignite auth, but external auth. Here I
>> am
>>>>>>>>> considering
>>>>>>>>>> Ignite Service Grid as a microservice platform.
>>>>>>>>>> Authentication microservice can be not related to Ignite at
>> all,
>>>> but
>>>>>>>>> author
>>>>>>>>>> of service may want to retrieve or authenticate user by
>> user_id,
>>>> that
>>>>>>> is
>>>>>>>>>> provided in request headers or context in jwt token, for
>> example.
>>>>>>>>>>
>>>>>>>>>> The same is for tracing or metrics. Ignite internal
>> mechanisms
>>>> here
>>>>>>>>> cannot
>>>>>>>>>> help at all, because there is no context related to user's
>> code.
>>>>>>>>>>
>>>>>>>>>> If we want to leave Ignite Service Grid as dump as possible,
>> it
>>>> is
>>>>>> ok.
>>>>>>>>> But
>>>>>>>>>> therefore it cannot compete with more functional variants.
>>>>>>>>>>
>>>>>>>>>> But just adding request headers at first step and custom
>>>> interceptors
>>>>>>>>>> (client and server side) we can give to user's of Ignite
>> Service
>>>>>> Grid
>>>>>>> a
>>>>>>>>>> lot of opportunities.
>>>>>>>>>>
>>>>>>>>>> There is an example of golang grpc middlewares -- see how
>> many
>>>>>>>>> interesting
>>>>>>>>>> use cases here:
>>>>>>>>>> https://github.com/grpc-ecosystem/go-grpc-middleware
>>>>>>>>>>
>>>>>>>>>> вт, 12 окт. 2021 г. в 07:31, Valentin Kulichenko <
>>>>>>>>>> valentin.kuliche...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Ivan,
>>>>>>>>>>>
>>>>>>>>>>> I'm a bit confused :) Unless I misread the initial
>> suggestion,
>>>> the
>>>>>>>>> idea is
>>>>>>>>>>> to provide a public API to create the context. In other
>> words,
>>>> it
>>>>>> will
>>>>>>>>> be
>>>>>>>>>>> up to the end user to create this context properly, which
>>>> affects
>>>>>> the
>>>>>>>>>>> business code - and that's exactly where I see an issue.
>>>>>>>>>>>
>>>>>>>>>>> The examples you mentioned are more related to internal
>>>> activities
>>>>>>>>> (e.g.,
>>>>>>>>>>> if authentication is handled by an Ignite server node, it
>> can
>>>> create
>>>>>>>>> its
>>>>>>>>>>> internal context for a connection - this is certainly
>>>> reasonable).
>>>>>> I'm
>>>>>>>>> only
>>>>>>>>>>> worried about exposing this to the end user.
>>>>>>>>>>>
>>>>>>>>>>> Maybe you can pick one of the use cases that you think would
>>>> benefit
>>>>>>>>> from
>>>>>>>>>>> this feature the most, and provide a little more detail? How
>>>> would
>>>>>> you
>>>>>>>>> like
>>>>>>>>>>> to see the use case to be addressed and what is currently
>>>> missing?
>>>>>>>>>>>
>>>>>>>>>>> Also, just to be clear: I'm not necessarily against the
>>>> suggestion,
>>>>>>> and
>>>>>>>>>>> it's highly unlikely that I will want to veto it if you or
>>>> someone
>>>>>>> else
>>>>>>>>>>> will decide to implement it. Just expressing my concerns.
>>>>>>>>>>>
>>>>>>>>>>> -Val
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Oct 10, 2021 at 11:52 PM Nikolay Izhikov <
>>>>>> nizhi...@apache.org
>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1 to have service proxy context.
>>>>>>>>>>>>
>>>>>>>>>>>>> 11 окт. 2021 г., в 09:43, Ivan Daschinsky <
>>>> ivanda...@gmail.com>
>>>>>>>>>>>> написал(а):
>>>>>>>>>>>>>
>>>>>>>>>>>>> Val, Pavel both of you are right, but on the other hand
>> there
>>>> are
>>>>>>>>> some
>>>>>>>>>>>>> other tasks
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Distributed tracing.
>>>>>>>>>>>>> 2. Custom metrics/measurements
>>>>>>>>>>>>> 3. Auth and some related tasks (i.e. ingests full User
>> info by
>>>>>>>>> calling
>>>>>>>>>>>> some
>>>>>>>>>>>>> auth service in middleware).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you both think that this is a good idea in business
>> code?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Without this functionality, our service grid cannot
>> compete
>>>> with
>>>>>>>>> grpc
>>>>>>>>>>> and
>>>>>>>>>>>>> others as microservice framework, unfortunately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But if we introduce limited support for this "request
>>>> headers", it
>>>>>>>>> can
>>>>>>>>>>>>> drastically improves this aspects of our service grid
>>>> framework.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> пн, 11 окт. 2021 г. в 00:48, Valentin Kulichenko <
>>>>>>>>>>>>> valentin.kuliche...@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with Pavel. The suggested approach is indeed
>> utilized
>>>>>>>>> quite
>>>>>>>>>>>>>> frequently, but it's inherently error-prone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The main issue is that it creates implicit assumptions
>> about
>>>> the
>>>>>>>>>>>> behavior
>>>>>>>>>>>>>> of both the service and the user's code. For example, if
>> the
>>>>>>>>> user's
>>>>>>>>>>> code
>>>>>>>>>>>>>> must provide a username, what if it doesn't? I assume it
>>>> will get
>>>>>>>>> an
>>>>>>>>>>>> error,
>>>>>>>>>>>>>> which is very counterintuitive. Even more importantly,
>> how
>>>> should
>>>>>>>>> one
>>>>>>>>>>>> learn
>>>>>>>>>>>>>> about this requirement in the first place? It is not
>>>> reflected in
>>>>>>>>> the
>>>>>>>>>>>> API
>>>>>>>>>>>>>> in any way - and that's a big problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fact that the service implementor needs to update
>> the API
>>>>>>>>> methods
>>>>>>>>>>>> when
>>>>>>>>>>>>>> such requirements are introduced is actually a good
>> thing,
>>>> in my
>>>>>>>>>>>> opinion.
>>>>>>>>>>>>>> This forces the developer to stop and think about how the
>>>> updated
>>>>>>>>> API
>>>>>>>>>>>>>> should look like and how to make sure it's
>>>> backward-compatible
>>>>>> (or
>>>>>>>>>>> not,
>>>>>>>>>>>> in
>>>>>>>>>>>>>> case the new requirements are mandatory). Doing this
>> through
>>>> an
>>>>>>>>>>> external
>>>>>>>>>>>>>> context is basically the equivalent of saying "let the
>> end
>>>> user
>>>>>>>>> deal
>>>>>>>>>>>> with
>>>>>>>>>>>>>> this". Not a good practice, in my view.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Conversely, passing everything exclusively via method
>>>> arguments
>>>>>>>>>>>> guarantees
>>>>>>>>>>>>>> that:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - The user's code is always compliant with the service
>>>>>>>>> contract. You
>>>>>>>>>>>>>> can't "forget" to pass something to the service.
>>>>>>>>>>>>>> - Any changes in the service contract
>> (backward-compatible
>>>> or
>>>>>>>>>>>> otherwise)
>>>>>>>>>>>>>> are explicitly reflected in the API.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Val
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Oct 10, 2021 at 6:21 AM Pavel Tupitsyn <
>>>>>>>>> ptupit...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, this approach is used by some other systems, and
>>>> still, I
>>>>>>>>> don't
>>>>>>>>>>>> like
>>>>>>>>>>>>>>> it very much.
>>>>>>>>>>>>>>> Let's hear more opinions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Oct 9, 2021 at 9:00 PM Ivan Daschinsky <
>>>>>>>>> ivanda...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>>> Pavel T., Ok, http rest dosn't have the clean design,
>> in
>>>> your
>>>>>>>>>>> opinion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But what about grpc? The same?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As for me, it is ok to pass additional parameters as
>> list
>>>> of
>>>>>>>>>>> key-value
>>>>>>>>>>>>>>>> pairs with keys as strings and values as bytearrays or
>>>> strings.
>>>>>>>>> It
>>>>>>>>>>> is
>>>>>>>>>>>>>> ok
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> allow user to set up middlewares for services and
>> allow to
>>>>>>>>> enrich
>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>> context in this middlewares. It is very common approach
>>>>>>>>> everywhere
>>>>>>>>>>> and
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> very useful in distributed systems. The use cases are
>> so
>>>>>>>>> obvious,
>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>> they?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> сб, 9 окт. 2021 г., 20:14 Pavel Tupitsyn <
>>>> ptupit...@apache.org
>>>>>>>>>> :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Pavel,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the explanation, I understand the use
>> cases.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> in REST service, he can set such parameters in
>> request
>>>>>> headers
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't consider HTTP-based services as a good
>> example of
>>>> a
>>>>>>>>>>>>>>>>> clean architecture.
>>>>>>>>>>>>>>>>> Data can be passed in URL parameters, in headers, and
>> in
>>>> body,
>>>>>>>>> and
>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> those ways has its own limitations.
>>>>>>>>>>>>>>>>> There is no obvious correct way to do things.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ambient state is not obvious and the API looks
>> confusing
>>>>>> even
>>>>>>>>>>>>>>> though I
>>>>>>>>>>>>>>>>> understand our services stack quite well both in Java
>> and
>>>> .NET
>>>>>>>>>>>>>>>>>> Can you clarify please?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The proposed API adds a "side channel" for the data.
>>>>>>>>>>>>>>>>> Some is passed as arguments, which is obvious, and
>> some
>>>>>> becomes
>>>>>>>>>>>>>>> magically
>>>>>>>>>>>>>>>>> available on the server side through some external
>>>> context.
>>>>>>>>>>>>>>>>> - You have to know about the context
>>>>>>>>>>>>>>>>> - You have to understand that the context is only
>>>> available
>>>>>>>>> during
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> method call (can't use it in some background logic)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In my opinion, this is a bit too clever. I'm a fan of
>> the
>>>>>>>>>>> functional
>>>>>>>>>>>>>>>>> programming approach where everything you need is
>> passed
>>>> as
>>>>>>>>>>>>>> arguments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Oct 8, 2021 at 4:29 PM Pavel Pereslegin <
>>>>>>>>> xxt...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Igor, Pavel.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why can not a user implement such context on
>> application
>>>>>>>>> level? I
>>>>>>>>>>>>>>>>>> believe Ignite provides all necessary tools for that.
>>>>>>>>>>>>>>>>>> The user wants to trace the source of the service
>> call.
>>>> For
>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> service must log the name of the user who made the
>> calls
>>>> of
>>>>>>>>> the
>>>>>>>>>>>>>>>>>> service. For now, there's no possibility to do that
>>>> without
>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>> the service interface and implementation. Moreover,
>> the
>>>> user
>>>>>>>>> must
>>>>>>>>>>>>>>>>>> modify all methods of service to pass this
>> parameter. For
>>>>>>>>> example,
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> REST service, he can set such parameters in request
>>>> headers,
>>>>>>>>> why
>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> can't provide such usability in Ignite.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This will reduce the performance of all calls
>>>>>>>>>>>>>>>>>> This feature is optional, if the context is not
>> passed -
>>>> then
>>>>>>>>>>>>>> there's
>>>>>>>>>>>>>>>>>> shouldn't be any performance difference.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ambient state is not obvious and the API looks
>> confusing
>>>>>> even
>>>>>>>>>>>>>>> though
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>> understand our services stack quite well both in
>> Java and
>>>>>> .NET
>>>>>>>>>>>>>>>>>> Can you clarify please?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> пт, 8 окт. 2021 г. в 15:46, Pavel Tupitsyn <
>>>>>>>>> ptupit...@apache.org
>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Agree with Igor.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm not sure this feature is a good fit for Ignite.
>>>>>>>>>>>>>>>>>>> Ignite should not be responsible for such a
>> high-level
>>>>>>>>> concept,
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>> be on the application side instead.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - As Eduard noted, it is hard to make this type-safe
>>>>>>>>>>>>>>>>>>> - Ambient state is not obvious and the API looks
>>>> confusing
>>>>>>>>> even
>>>>>>>>>>>>>>>> though
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> understand our services stack quite well both in
>> Java
>>>> and
>>>>>>>>> .NET
>>>>>>>>>>>>>>>>>>> - This will reduce the performance of all calls
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Oct 8, 2021 at 3:44 PM Igor Sapego <
>>>>>>>>> isap...@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Why can not a user implement such context on
>>>> application
>>>>>>>>> level?
>>>>>>>>>>>>>>>>>>>> I believe Ignite provides all necessary tools for
>> that.
>>>>>> User
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>> implement such a context as user type and pass it
>> to
>>>>>>>>> services
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>> need. Are the arguments why would Ignite need a
>>>> separate
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>> for such a use case?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Oct 8, 2021 at 2:17 PM Eduard Rakhmankulov
>> <
>>>>>>>>>>>>>>>>>> erixon...@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am not aware .NET capabilities, but as I can see
>>>> service
>>>>>>>>>>>>>> must
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> implemented in *java* and even if can't serialize
>>>> other
>>>>>>>>> that
>>>>>>>>>>>>>>> Map
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> .NET
>>>>>>>>>>>>>>>>>>>>> side, on java side we can wrap this map with
>> provided
>>>>>>>>>>>>>>>> TypedContext
>>>>>>>>>>>>>>>>>>>> (context
>>>>>>>>>>>>>>>>>>>>> should be convertible from map in this case).
>>>>>>>>>>>>>>>>>>>>> That leads to a situation when Java can use
>>>> TypedContext
>>>>>>>>> but
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>> clients
>>>>>>>>>>>>>>>>>>>>> can't. I believe that the majority of services
>> users
>>>> are
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> should be taken in accordance.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> P.S. I think it is possible to send plain objects
>> from
>>>>>> .NET
>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> cluster.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Best regards, Ed
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin <
>>>>>>>>>>>>>>> xxt...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi, Eduard!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks for your feedback.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The idea sounds very good, but don't forget
>> about the
>>>>>>>>>>>>>>> platform
>>>>>>>>>>>>>>>>>>>> services.
>>>>>>>>>>>>>>>>>>>>>> For example, we may call Java service from .Net
>> and
>>>>>>>>>>>>>>> vice-versa.
>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>> not sure if the context can be implemented as a
>>>> custom
>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>> (instead
>>>>>>>>>>>>>>>>>>>>>> of Map/Dictionary) in this case.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> пт, 8 окт. 2021 г. в 14:21, Eduard Rakhmankulov <
>>>>>>>>>>>>>>>>>> erixon...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi, Pavel
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Is it possible to provide type-safe API for
>>>>>>>>>>>>>>>>> ServiceProxyContext ?
>>>>>>>>>>>>>>>>>>>>>>> I think constructions like int arg1 =
>>>>>>>>>>>>>>> ctx.attribute("arg1");
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>>>>>>>>> prone.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Can we make something like this :
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> //Signature with two generic params which allow
>> the
>>>>>>>>>>>>>>> compiler
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>>>>> if the service will be called with the wrong
>> type
>>>>>>>>>>>>>> context.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> public <T extends ContextedWith<CtxType>,
>> CtxType> T
>>>>>>>>>>>>>>>>>>>>>>> serviceProxyTyped(ClusterGroup prj, String name,
>>>> Class<?
>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>> T
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> srvcCls, CtxType optCtx, boolean sticky, long
>>>> timeout)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> //new interface which services with scoped
>> context
>>>>>> should
>>>>>>>>>>>>>>>>>> implement
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> public interface ContextedWith<T> {
>>>>>>>>>>>>>>>>>>>>>>> T getCtx();
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> // implementation can delegate to Map-like
>> context
>>>> or be
>>>>>>>>>>>>>>>> POJO.
>>>>>>>>>>>>>>>>>>>>>>> interface MyServiceContext {
>>>>>>>>>>>>>>>>>>>>>>> int getArg1();
>>>>>>>>>>>>>>>>>>>>>>> String getUserId();
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> class MyService implements
>>>>>>>>>>>>>> ContextedWith<MyServiceContext>
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> void doThings() {
>>>>>>>>>>>>>>>>>>>>>>> MyServiceContext ctx = getCtx();
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> System.out.println("ctx.getArg1() = " +
>>>> ctx.getArg1());
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> @Override public MyServiceContext getCtx() {
>>>>>>>>>>>>>>>>>>>>>>> return ServiceProxyContext.current();
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Best regards, Ed.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin <
>>>>>>>>>>>>>>>>> xxt...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hello Igniters!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I want to implement a feature to support a
>> custom
>>>>>>>>>>>>>>> "caller"
>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>> ignite services (see example in ticket
>> description
>>>>>>>>>>>>>> [1]).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sometimes, when using Ignite services, it
>> becomes
>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> pass
>>>>>>>>>>>>>>>>>>>>>>>> custom parameters from the "request source" to
>> the
>>>>>>>>>>>>>>> service.
>>>>>>>>>>>>>>>>>> This is
>>>>>>>>>>>>>>>>>>>>>>>> most commonly used to track the origin of a
>> service
>>>>>>>>>>>>>> call
>>>>>>>>>>>>>>>>> (user
>>>>>>>>>>>>>>>>>> id,
>>>>>>>>>>>>>>>>>>>>>>>> request id, session id eg see this user
>> question
>>>> [2]).
>>>>>>>>>>>>>>>>>>>>>>>> At the moment, the only way to pass such
>>>> parameters to
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> service is
>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>>> adding argument(s) to all called methods of the
>>>>>>>>>>>>>> service,
>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>> makes
>>>>>>>>>>>>>>>>>>>>>>>> the code messy and also complicates
>> development and
>>>>>>>>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I propose letting the user set a custom context
>>>> for the
>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>> proxy
>>>>>>>>>>>>>>>>>>>>>>>> and implicitly pass that context to the methods
>>>> being
>>>>>>>>>>>>>>>> called.
>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>>>>>> function should not affect the execution of
>> service
>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>>>>>>>> unless the user has specified a context.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> An example of using the proposed API [1].
>>>>>>>>>>>>>>>>>>>>>>>> PoC (except thin clients) [3].
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>> https://issues.apache.org/jira/browse/IGNITE-15572
>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
>>>>>>>>>>>>>>>>>>>>>>>> [3] https://github.com/apache/ignite/pull/9440
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sincerely yours, Ivan Daschinskiy
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sincerely yours, Ivan Daschinskiy
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sincerely yours, Ivan Daschinskiy
>>>>>>
>>>>
>>
