A new feedback has been added : 19
A new feedback has been added, go to bugyard.io to see all the details... https://bugyard.io A new feedback has been added "We don't have code samples for .NET here. Also, the C++ should be removed, right? I don't think that the services are available for C++" by dmagda View feedback https://app.bugyard.io/web/app/rycqZJDyY/f/61605414189ee70014d3aef6
Re: [DISCUSS] Custom service proxy context
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 :
>
> 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 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
> > 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 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 :
> > > > >
> > > > > 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 , CtxType> T
> > > > > serviceProxyTyped(ClusterGroup prj, String name, Class
> > > > > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> > > > >
> > > > > //new interface which services with scoped context should implement
> > > > >
> > > > > public interface ContextedWith {
> > > > > T getCtx();
> > > > > }
> > > > >
> > > > > // implementation can delegate to Map-like context or be POJO.
> > > > > interface MyServiceContext {
> > > > > int getArg1();
> > > > > String getUserId();
> > > > > }
> > > > >
> > > > > class MyService implements ContextedWith {
> > > > > 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
> > > 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]).
> > >
Re: [DISCUSS] Custom service proxy context
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 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
> 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 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 :
> > > >
> > > > 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 , CtxType> T
> > > > serviceProxyTyped(ClusterGroup prj, String name, Class
> > > > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> > > >
> > > > //new interface which services with scoped context should implement
> > > >
> > > > public interface ContextedWith {
> > > > T getCtx();
> > > > }
> > > >
> > > > // implementation can delegate to Map-like context or be POJO.
> > > > interface MyServiceContext {
> > > > int getArg1();
> > > > String getUserId();
> > > > }
> > > >
> > > > class MyService implements ContextedWith {
> > > > 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
> > 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
> > > > >
> > >
> >
>
Re: [DISCUSS] Custom service proxy context
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
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 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 :
> > >
> > > 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 , CtxType> T
> > > serviceProxyTyped(ClusterGroup prj, String name, Class
> > > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> > >
> > > //new interface which services with scoped context should implement
> > >
> > > public interface ContextedWith {
> > > T getCtx();
> > > }
> > >
> > > // implementation can delegate to Map-like context or be POJO.
> > > interface MyServiceContext {
> > > int getArg1();
> > > String getUserId();
> > > }
> > >
> > > class MyService implements ContextedWith {
> > > 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
> 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
> > > >
> >
>
Re: [DISCUSS] Custom service proxy context
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 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 :
> >
> > 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 , CtxType> T
> > serviceProxyTyped(ClusterGroup prj, String name, Class
> > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> >
> > //new interface which services with scoped context should implement
> >
> > public interface ContextedWith {
> > T getCtx();
> > }
> >
> > // implementation can delegate to Map-like context or be POJO.
> > interface MyServiceContext {
> > int getArg1();
> > String getUserId();
> > }
> >
> > class MyService implements ContextedWith {
> > 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 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
> > >
>
Re: [DISCUSS] Custom service proxy context
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 :
>
> 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 , CtxType> T
> serviceProxyTyped(ClusterGroup prj, String name, Class
> srvcCls, CtxType optCtx, boolean sticky, long timeout)
>
> //new interface which services with scoped context should implement
>
> public interface ContextedWith {
> T getCtx();
> }
>
> // implementation can delegate to Map-like context or be POJO.
> interface MyServiceContext {
> int getArg1();
> String getUserId();
> }
>
> class MyService implements ContextedWith {
> 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 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
> >
Re: [DISCUSS] Custom service proxy context
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 , CtxType> T
serviceProxyTyped(ClusterGroup prj, String name, Class
srvcCls, CtxType optCtx, boolean sticky, long timeout)
//new interface which services with scoped context should implement
public interface ContextedWith {
T getCtx();
}
// implementation can delegate to Map-like context or be POJO.
interface MyServiceContext {
int getArg1();
String getUserId();
}
class MyService implements ContextedWith {
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 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
>
[DISCUSS] Custom service proxy context
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
