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
> > > > >
> > >
> >
>
