> 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.
I like this idea and I have filed a ticket for this change [1]. If there is no objection, I plan to implement this shortly. [1] https://issues.apache.org/jira/browse/IGNITE-15801 ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov <nizhi...@apache.org>: > > > 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 > >>>>>> > >>>> > >> >
