IEP-46 Thin client - Service invocation

[Alexey Plekhanov]

Hello Igniters,

I have plans to implement service invocation in thin clients. I've already
implemented a PoC for java thin client and want to discuss some details.
Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin
client [2].

To invoke the service method by java thick client we can get service proxy
by:
IgniteServices.serviceProxy(String name, Class<? super T> svcItf, boolean
sticky, long timeout)
and then invoke the method on this proxy.

Also, we already have service invocation functionality for .Net thick
client (see PlatformServices class). For .Net thick client there are two
types of operation related to service invocation: create a proxy and invoke
a method (this approach is identical to java thick client).

But I think we can't use two operations for thin clients. If we create a
proxy by a separate operation we should store this resource somewhere on
server-side and we should also have an ability to close this resource when
it's not needed anymore. So there is an additional operation on client-side
needed to close the proxy explicitly. This is more complex from users point
of view than the current approach for java thick client, so I think it's
better to use only one operation for thin clients: OP_SERVICE_INVOKE and
create a service proxy on each method invocation. In this case, each
request should have at least these parameters: service name, interface
name, timeout, nodes set, method name, and args (sticky flag is useless
since we always will create a new proxy for each request).

There is one more problem: methods of some interface can be overloaded. In
.Net thick client implementation there is a method used to find an
appropriate service method to invoke by method name and args values:
PlatformServices.ServiceProxyHolder#getMethod. Since we use here only args
values (don't have full information about args types) sometimes we can get
an error for overloaded methods. For example, if you have an interface like:

public interface TestServiceInterface {
    public String testMethod(String val);
    public String testMethod(Object val);
}

And invoke service like:

Object arg = null;
svc.testMethod(arg);

Java will resolve the correct method to call on client-side, but using only
arg value (null) it's impossible to get exactly one method on the
server-side (PlatformServices.ServiceProxyHolder#getMethod will throw an
error in this case: Ambiguous proxy method 'testMethod')

To solve this problem we can pass full method signature (method name with
parameters types) instead of just method name. Or we can additionally pass
argument types to find exactly one method by Class.getMethod(String name,
Class<?>... parameterTypes). Also, we can support two approaches at the
same time: just the method name to simplify the implementation of non-java
thin clients, and full method signature to deal with overloaded methods.

So,
What do you think about single operation for service invocation (create
service proxy on each invoke request)?
What do you think about ways to resolve the method?

[1] :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
[2] : https://issues.apache.org/jira/browse/IGNITE-12754

[Pavel Tupitsyn]

Hi Alex,

Thanks for starting this thread.
I've created the IEP some time ago but then got distracted by other things.

My thoughts:

*1. Create service proxy on each invoke request*
Single client operation is a lot simpler to implement on both sides (client
and server), so I would prefer this way.
The only concern here is performance. My plan was to benchmark and then
decide.

*2. Method resolution*
Taking Python and other dynamically typed languages into account,
current PlatformService implementation seems to be the best fit.

If we decide to add an optional signature, we should not make it
Java-specific:
use binary type IDs (that are already part of the protocol) to specify
parameter types.


On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <[hidden email]>
wrote:

> Hello Igniters,
>
> I have plans to implement service invocation in thin clients. I've already
> implemented a PoC for java thin client and want to discuss some details.
> Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin
> client [2].
>
> To invoke the service method by java thick client we can get service proxy
> by:
> IgniteServices.serviceProxy(String name, Class<? super T> svcItf, boolean
> sticky, long timeout)
> and then invoke the method on this proxy.
>
> Also, we already have service invocation functionality for .Net thick
> client (see PlatformServices class). For .Net thick client there are two
> types of operation related to service invocation: create a proxy and invoke
> a method (this approach is identical to java thick client).
>
> But I think we can't use two operations for thin clients. If we create a
> proxy by a separate operation we should store this resource somewhere on
> server-side and we should also have an ability to close this resource when
> it's not needed anymore. So there is an additional operation on client-side
> needed to close the proxy explicitly. This is more complex from users point
> of view than the current approach for java thick client, so I think it's
> better to use only one operation for thin clients: OP_SERVICE_INVOKE and
> create a service proxy on each method invocation. In this case, each
> request should have at least these parameters: service name, interface
> name, timeout, nodes set, method name, and args (sticky flag is useless
> since we always will create a new proxy for each request).
>
> There is one more problem: methods of some interface can be overloaded. In
> .Net thick client implementation there is a method used to find an
> appropriate service method to invoke by method name and args values:
> PlatformServices.ServiceProxyHolder#getMethod. Since we use here only args
> values (don't have full information about args types) sometimes we can get
> an error for overloaded methods. For example, if you have an interface
> like:
>
> public interface TestServiceInterface {
>     public String testMethod(String val);
>     public String testMethod(Object val);
> }
>
> And invoke service like:
>
> Object arg = null;
> svc.testMethod(arg);
>
> Java will resolve the correct method to call on client-side, but using only
> arg value (null) it's impossible to get exactly one method on the
> server-side (PlatformServices.ServiceProxyHolder#getMethod will throw an
> error in this case: Ambiguous proxy method 'testMethod')
>
> To solve this problem we can pass full method signature (method name with
> parameters types) instead of just method name. Or we can additionally pass
> argument types to find exactly one method by Class.getMethod(String name,
> Class<?>... parameterTypes). Also, we can support two approaches at the
> same time: just the method name to simplify the implementation of non-java
> thin clients, and full method signature to deal with overloaded methods.
>
> So,
> What do you think about single operation for service invocation (create
> service proxy on each invoke request)?
> What do you think about ways to resolve the method?
>
> [1] :
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> [2] : https://issues.apache.org/jira/browse/IGNITE-12754
>

[Alexey Plekhanov]

Pavel,

I've moved proposals from this thread to the IEP [1] and described changes
to protocol, please have a look.

[1] :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation

пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:

> Hi Alex,
>
> Thanks for starting this thread.
> I've created the IEP some time ago but then got distracted by other things.
>
> My thoughts:
>
> *1. Create service proxy on each invoke request*
> Single client operation is a lot simpler to implement on both sides (client
> and server), so I would prefer this way.
> The only concern here is performance. My plan was to benchmark and then
> decide.
>
> *2. Method resolution*
> Taking Python and other dynamically typed languages into account,
> current PlatformService implementation seems to be the best fit.
>
> If we decide to add an optional signature, we should not make it
> Java-specific:
> use binary type IDs (that are already part of the protocol) to specify
> parameter types.
>
>
> On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <[hidden email]>
> wrote:
>
> > Hello Igniters,
> >
> > I have plans to implement service invocation in thin clients. I've
> already
> > implemented a PoC for java thin client and want to discuss some details.
> > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin
> > client [2].
> >
> > To invoke the service method by java thick client we can get service
> proxy
> > by:
> > IgniteServices.serviceProxy(String name, Class<? super T> svcItf, boolean
> > sticky, long timeout)
> > and then invoke the method on this proxy.
> >
> > Also, we already have service invocation functionality for .Net thick
> > client (see PlatformServices class). For .Net thick client there are two
> > types of operation related to service invocation: create a proxy and
> invoke
> > a method (this approach is identical to java thick client).
> >
> > But I think we can't use two operations for thin clients. If we create a
> > proxy by a separate operation we should store this resource somewhere on
> > server-side and we should also have an ability to close this resource
> when
> > it's not needed anymore. So there is an additional operation on
> client-side
> > needed to close the proxy explicitly. This is more complex from users
> point
> > of view than the current approach for java thick client, so I think it's
> > better to use only one operation for thin clients: OP_SERVICE_INVOKE and
> > create a service proxy on each method invocation. In this case, each
> > request should have at least these parameters: service name, interface
> > name, timeout, nodes set, method name, and args (sticky flag is useless
> > since we always will create a new proxy for each request).
> >
> > There is one more problem: methods of some interface can be overloaded.
> In
> > .Net thick client implementation there is a method used to find an
> > appropriate service method to invoke by method name and args values:
> > PlatformServices.ServiceProxyHolder#getMethod. Since we use here only
> args
> > values (don't have full information about args types) sometimes we can
> get
> > an error for overloaded methods. For example, if you have an interface
> > like:
> >
> > public interface TestServiceInterface {
> >     public String testMethod(String val);
> >     public String testMethod(Object val);
> > }
> >
> > And invoke service like:
> >
> > Object arg = null;
> > svc.testMethod(arg);
> >
> > Java will resolve the correct method to call on client-side, but using
> only
> > arg value (null) it's impossible to get exactly one method on the
> > server-side (PlatformServices.ServiceProxyHolder#getMethod will throw an
> > error in this case: Ambiguous proxy method 'testMethod')
> >
> > To solve this problem we can pass full method signature (method name with
> > parameters types) instead of just method name. Or we can additionally
> pass
> > argument types to find exactly one method by Class.getMethod(String name,
> > Class<?>... parameterTypes). Also, we can support two approaches at the
> > same time: just the method name to simplify the implementation of
> non-java
> > thin clients, and full method signature to deal with overloaded methods.
> >
> > So,
> > What do you think about single operation for service invocation (create
> > service proxy on each invoke request)?
> > What do you think about ways to resolve the method?
> >
> > [1] :
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
> >
>

[Pavel Tupitsyn]

Alex,

IEP looks good to me in general.

One question: what is `Interface name` in the request?
As I understand, service name is enough to retrieve ServiceDescriptor,
and then we can get serviceClass from there.

On Wed, May 20, 2020 at 12:42 PM Alex Plehanov <[hidden email]>
wrote:

> Pavel,
>
> I've moved proposals from this thread to the IEP [1] and described changes
> to protocol, please have a look.
>
> [1] :
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
>
> пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:
>
> > Hi Alex,
> >
> > Thanks for starting this thread.
> > I've created the IEP some time ago but then got distracted by other
> things.
> >
> > My thoughts:
> >
> > *1. Create service proxy on each invoke request*
> > Single client operation is a lot simpler to implement on both sides
> (client
> > and server), so I would prefer this way.
> > The only concern here is performance. My plan was to benchmark and then
> > decide.
> >
> > *2. Method resolution*
> > Taking Python and other dynamically typed languages into account,
> > current PlatformService implementation seems to be the best fit.
> >
> > If we decide to add an optional signature, we should not make it
> > Java-specific:
> > use binary type IDs (that are already part of the protocol) to specify
> > parameter types.
> >
> >
> > On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <[hidden email]>
> > wrote:
> >
> > > Hello Igniters,
> > >
> > > I have plans to implement service invocation in thin clients. I've
> > already
> > > implemented a PoC for java thin client and want to discuss some
> details.
> > > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin
> > > client [2].
> > >
> > > To invoke the service method by java thick client we can get service
> > proxy
> > > by:
> > > IgniteServices.serviceProxy(String name, Class<? super T> svcItf,
> boolean
> > > sticky, long timeout)
> > > and then invoke the method on this proxy.
> > >
> > > Also, we already have service invocation functionality for .Net thick
> > > client (see PlatformServices class). For .Net thick client there are
> two
> > > types of operation related to service invocation: create a proxy and
> > invoke
> > > a method (this approach is identical to java thick client).
> > >
> > > But I think we can't use two operations for thin clients. If we create
> a
> > > proxy by a separate operation we should store this resource somewhere
> on
> > > server-side and we should also have an ability to close this resource
> > when
> > > it's not needed anymore. So there is an additional operation on
> > client-side
> > > needed to close the proxy explicitly. This is more complex from users
> > point
> > > of view than the current approach for java thick client, so I think
> it's
> > > better to use only one operation for thin clients: OP_SERVICE_INVOKE
> and
> > > create a service proxy on each method invocation. In this case, each
> > > request should have at least these parameters: service name, interface
> > > name, timeout, nodes set, method name, and args (sticky flag is useless
> > > since we always will create a new proxy for each request).
> > >
> > > There is one more problem: methods of some interface can be overloaded.
> > In
> > > .Net thick client implementation there is a method used to find an
> > > appropriate service method to invoke by method name and args values:
> > > PlatformServices.ServiceProxyHolder#getMethod. Since we use here only
> > args
> > > values (don't have full information about args types) sometimes we can
> > get
> > > an error for overloaded methods. For example, if you have an interface
> > > like:
> > >
> > > public interface TestServiceInterface {
> > >     public String testMethod(String val);
> > >     public String testMethod(Object val);
> > > }
> > >
> > > And invoke service like:
> > >
> > > Object arg = null;
> > > svc.testMethod(arg);
> > >
> > > Java will resolve the correct method to call on client-side, but using
> > only
> > > arg value (null) it's impossible to get exactly one method on the
> > > server-side (PlatformServices.ServiceProxyHolder#getMethod will throw
> an
> > > error in this case: Ambiguous proxy method 'testMethod')
> > >
> > > To solve this problem we can pass full method signature (method name
> with
> > > parameters types) instead of just method name. Or we can additionally
> > pass
> > > argument types to find exactly one method by Class.getMethod(String
> name,
> > > Class<?>... parameterTypes). Also, we can support two approaches at the
> > > same time: just the method name to simplify the implementation of
> > non-java
> > > thin clients, and full method signature to deal with overloaded
> methods.
> > >
> > > So,
> > > What do you think about single operation for service invocation (create
> > > service proxy on each invoke request)?
> > > What do you think about ways to resolve the method?
> > >
> > > [1] :
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
> > >
> >
>

[Alexey Plekhanov]

Pavel,

Yes, looks like we can get this information from ServiceDescriptor. I've
removed 'interface name' from requests in IEP. Thank you!

ср, 20 мая 2020 г. в 12:58, Pavel Tupitsyn <[hidden email]>:

> Alex,
>
> IEP looks good to me in general.
>
> One question: what is `Interface name` in the request?
> As I understand, service name is enough to retrieve ServiceDescriptor,
> and then we can get serviceClass from there.
>
> On Wed, May 20, 2020 at 12:42 PM Alex Plehanov <[hidden email]>
> wrote:
>
> > Pavel,
> >
> > I've moved proposals from this thread to the IEP [1] and described
> changes
> > to protocol, please have a look.
> >
> > [1] :
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> >
> > пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:
> >
> > > Hi Alex,
> > >
> > > Thanks for starting this thread.
> > > I've created the IEP some time ago but then got distracted by other
> > things.
> > >
> > > My thoughts:
> > >
> > > *1. Create service proxy on each invoke request*
> > > Single client operation is a lot simpler to implement on both sides
> > (client
> > > and server), so I would prefer this way.
> > > The only concern here is performance. My plan was to benchmark and then
> > > decide.
> > >
> > > *2. Method resolution*
> > > Taking Python and other dynamically typed languages into account,
> > > current PlatformService implementation seems to be the best fit.
> > >
> > > If we decide to add an optional signature, we should not make it
> > > Java-specific:
> > > use binary type IDs (that are already part of the protocol) to specify
> > > parameter types.
> > >
> > >
> > > On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <[hidden email]
> >
> > > wrote:
> > >
> > > > Hello Igniters,
> > > >
> > > > I have plans to implement service invocation in thin clients. I've
> > > already
> > > > implemented a PoC for java thin client and want to discuss some
> > details.
> > > > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net thin
> > > > client [2].
> > > >
> > > > To invoke the service method by java thick client we can get service
> > > proxy
> > > > by:
> > > > IgniteServices.serviceProxy(String name, Class<? super T> svcItf,
> > boolean
> > > > sticky, long timeout)
> > > > and then invoke the method on this proxy.
> > > >
> > > > Also, we already have service invocation functionality for .Net thick
> > > > client (see PlatformServices class). For .Net thick client there are
> > two
> > > > types of operation related to service invocation: create a proxy and
> > > invoke
> > > > a method (this approach is identical to java thick client).
> > > >
> > > > But I think we can't use two operations for thin clients. If we
> create
> > a
> > > > proxy by a separate operation we should store this resource somewhere
> > on
> > > > server-side and we should also have an ability to close this resource
> > > when
> > > > it's not needed anymore. So there is an additional operation on
> > > client-side
> > > > needed to close the proxy explicitly. This is more complex from users
> > > point
> > > > of view than the current approach for java thick client, so I think
> > it's
> > > > better to use only one operation for thin clients: OP_SERVICE_INVOKE
> > and
> > > > create a service proxy on each method invocation. In this case, each
> > > > request should have at least these parameters: service name,
> interface
> > > > name, timeout, nodes set, method name, and args (sticky flag is
> useless
> > > > since we always will create a new proxy for each request).
> > > >
> > > > There is one more problem: methods of some interface can be
> overloaded.
> > > In
> > > > .Net thick client implementation there is a method used to find an
> > > > appropriate service method to invoke by method name and args values:
> > > > PlatformServices.ServiceProxyHolder#getMethod. Since we use here only
> > > args
> > > > values (don't have full information about args types) sometimes we
> can
> > > get
> > > > an error for overloaded methods. For example, if you have an
> interface
> > > > like:
> > > >
> > > > public interface TestServiceInterface {
> > > >     public String testMethod(String val);
> > > >     public String testMethod(Object val);
> > > > }
> > > >
> > > > And invoke service like:
> > > >
> > > > Object arg = null;
> > > > svc.testMethod(arg);
> > > >
> > > > Java will resolve the correct method to call on client-side, but
> using
> > > only
> > > > arg value (null) it's impossible to get exactly one method on the
> > > > server-side (PlatformServices.ServiceProxyHolder#getMethod will throw
> > an
> > > > error in this case: Ambiguous proxy method 'testMethod')
> > > >
> > > > To solve this problem we can pass full method signature (method name
> > with
> > > > parameters types) instead of just method name. Or we can additionally
> > > pass
> > > > argument types to find exactly one method by Class.getMethod(String
> > name,
> > > > Class<?>... parameterTypes). Also, we can support two approaches at
> the
> > > > same time: just the method name to simplify the implementation of
> > > non-java
> > > > thin clients, and full method signature to deal with overloaded
> > methods.
> > > >
> > > > So,
> > > > What do you think about single operation for service invocation
> (create
> > > > service proxy on each invoke request)?
> > > > What do you think about ways to resolve the method?
> > > >
> > > > [1] :
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > > > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
> > > >
> > >
> >
>

[Pavel Tupitsyn]

Alex,

Thank you, the IEP looks complete now.

Are you going to do the comparison benchmark of 1-operation vs 2-operation
modes?
I can do that too, just want to avoid duplicate work.

On Wed, May 20, 2020 at 1:17 PM Alex Plehanov <[hidden email]>
wrote:

> Pavel,
>
> Yes, looks like we can get this information from ServiceDescriptor. I've
> removed 'interface name' from requests in IEP. Thank you!
>
> ср, 20 мая 2020 г. в 12:58, Pavel Tupitsyn <[hidden email]>:
>
> > Alex,
> >
> > IEP looks good to me in general.
> >
> > One question: what is `Interface name` in the request?
> > As I understand, service name is enough to retrieve ServiceDescriptor,
> > and then we can get serviceClass from there.
> >
> > On Wed, May 20, 2020 at 12:42 PM Alex Plehanov <[hidden email]>
> > wrote:
> >
> > > Pavel,
> > >
> > > I've moved proposals from this thread to the IEP [1] and described
> > changes
> > > to protocol, please have a look.
> > >
> > > [1] :
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > >
> > > пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Hi Alex,
> > > >
> > > > Thanks for starting this thread.
> > > > I've created the IEP some time ago but then got distracted by other
> > > things.
> > > >
> > > > My thoughts:
> > > >
> > > > *1. Create service proxy on each invoke request*
> > > > Single client operation is a lot simpler to implement on both sides
> > > (client
> > > > and server), so I would prefer this way.
> > > > The only concern here is performance. My plan was to benchmark and
> then
> > > > decide.
> > > >
> > > > *2. Method resolution*
> > > > Taking Python and other dynamically typed languages into account,
> > > > current PlatformService implementation seems to be the best fit.
> > > >
> > > > If we decide to add an optional signature, we should not make it
> > > > Java-specific:
> > > > use binary type IDs (that are already part of the protocol) to
> specify
> > > > parameter types.
> > > >
> > > >
> > > > On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Hello Igniters,
> > > > >
> > > > > I have plans to implement service invocation in thin clients. I've
> > > > already
> > > > > implemented a PoC for java thin client and want to discuss some
> > > details.
> > > > > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net
> thin
> > > > > client [2].
> > > > >
> > > > > To invoke the service method by java thick client we can get
> service
> > > > proxy
> > > > > by:
> > > > > IgniteServices.serviceProxy(String name, Class<? super T> svcItf,
> > > boolean
> > > > > sticky, long timeout)
> > > > > and then invoke the method on this proxy.
> > > > >
> > > > > Also, we already have service invocation functionality for .Net
> thick
> > > > > client (see PlatformServices class). For .Net thick client there
> are
> > > two
> > > > > types of operation related to service invocation: create a proxy
> and
> > > > invoke
> > > > > a method (this approach is identical to java thick client).
> > > > >
> > > > > But I think we can't use two operations for thin clients. If we
> > create
> > > a
> > > > > proxy by a separate operation we should store this resource
> somewhere
> > > on
> > > > > server-side and we should also have an ability to close this
> resource
> > > > when
> > > > > it's not needed anymore. So there is an additional operation on
> > > > client-side
> > > > > needed to close the proxy explicitly. This is more complex from
> users
> > > > point
> > > > > of view than the current approach for java thick client, so I think
> > > it's
> > > > > better to use only one operation for thin clients:
> OP_SERVICE_INVOKE
> > > and
> > > > > create a service proxy on each method invocation. In this case,
> each
> > > > > request should have at least these parameters: service name,
> > interface
> > > > > name, timeout, nodes set, method name, and args (sticky flag is
> > useless
> > > > > since we always will create a new proxy for each request).
> > > > >
> > > > > There is one more problem: methods of some interface can be
> > overloaded.
> > > > In
> > > > > .Net thick client implementation there is a method used to find an
> > > > > appropriate service method to invoke by method name and args
> values:
> > > > > PlatformServices.ServiceProxyHolder#getMethod. Since we use here
> only
> > > > args
> > > > > values (don't have full information about args types) sometimes we
> > can
> > > > get
> > > > > an error for overloaded methods. For example, if you have an
> > interface
> > > > > like:
> > > > >
> > > > > public interface TestServiceInterface {
> > > > >     public String testMethod(String val);
> > > > >     public String testMethod(Object val);
> > > > > }
> > > > >
> > > > > And invoke service like:
> > > > >
> > > > > Object arg = null;
> > > > > svc.testMethod(arg);
> > > > >
> > > > > Java will resolve the correct method to call on client-side, but
> > using
> > > > only
> > > > > arg value (null) it's impossible to get exactly one method on the
> > > > > server-side (PlatformServices.ServiceProxyHolder#getMethod will
> throw
> > > an
> > > > > error in this case: Ambiguous proxy method 'testMethod')
> > > > >
> > > > > To solve this problem we can pass full method signature (method
> name
> > > with
> > > > > parameters types) instead of just method name. Or we can
> additionally
> > > > pass
> > > > > argument types to find exactly one method by Class.getMethod(String
> > > name,
> > > > > Class<?>... parameterTypes). Also, we can support two approaches at
> > the
> > > > > same time: just the method name to simplify the implementation of
> > > > non-java
> > > > > thin clients, and full method signature to deal with overloaded
> > > methods.
> > > > >
> > > > > So,
> > > > > What do you think about single operation for service invocation
> > (create
> > > > > service proxy on each invoke request)?
> > > > > What do you think about ways to resolve the method?
> > > > >
> > > > > [1] :
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > > > > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
> > > > >
> > > >
> > >
> >
>

[Alexey Plekhanov]

Pavel,

I will try to benchmark by myself. Thank you.

ср, 20 мая 2020 г. в 13:54, Pavel Tupitsyn <[hidden email]>:

> Alex,
>
> Thank you, the IEP looks complete now.
>
> Are you going to do the comparison benchmark of 1-operation vs 2-operation
> modes?
> I can do that too, just want to avoid duplicate work.
>
> On Wed, May 20, 2020 at 1:17 PM Alex Plehanov <[hidden email]>
> wrote:
>
> > Pavel,
> >
> > Yes, looks like we can get this information from ServiceDescriptor. I've
> > removed 'interface name' from requests in IEP. Thank you!
> >
> > ср, 20 мая 2020 г. в 12:58, Pavel Tupitsyn <[hidden email]>:
> >
> > > Alex,
> > >
> > > IEP looks good to me in general.
> > >
> > > One question: what is `Interface name` in the request?
> > > As I understand, service name is enough to retrieve ServiceDescriptor,
> > > and then we can get serviceClass from there.
> > >
> > > On Wed, May 20, 2020 at 12:42 PM Alex Plehanov <
> [hidden email]>
> > > wrote:
> > >
> > > > Pavel,
> > > >
> > > > I've moved proposals from this thread to the IEP [1] and described
> > > changes
> > > > to protocol, please have a look.
> > > >
> > > > [1] :
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > > >
> > > > пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > Thanks for starting this thread.
> > > > > I've created the IEP some time ago but then got distracted by other
> > > > things.
> > > > >
> > > > > My thoughts:
> > > > >
> > > > > *1. Create service proxy on each invoke request*
> > > > > Single client operation is a lot simpler to implement on both sides
> > > > (client
> > > > > and server), so I would prefer this way.
> > > > > The only concern here is performance. My plan was to benchmark and
> > then
> > > > > decide.
> > > > >
> > > > > *2. Method resolution*
> > > > > Taking Python and other dynamically typed languages into account,
> > > > > current PlatformService implementation seems to be the best fit.
> > > > >
> > > > > If we decide to add an optional signature, we should not make it
> > > > > Java-specific:
> > > > > use binary type IDs (that are already part of the protocol) to
> > specify
> > > > > parameter types.
> > > > >
> > > > >
> > > > > On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <
> > [hidden email]
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hello Igniters,
> > > > > >
> > > > > > I have plans to implement service invocation in thin clients.
> I've
> > > > > already
> > > > > > implemented a PoC for java thin client and want to discuss some
> > > > details.
> > > > > > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net
> > thin
> > > > > > client [2].
> > > > > >
> > > > > > To invoke the service method by java thick client we can get
> > service
> > > > > proxy
> > > > > > by:
> > > > > > IgniteServices.serviceProxy(String name, Class<? super T> svcItf,
> > > > boolean
> > > > > > sticky, long timeout)
> > > > > > and then invoke the method on this proxy.
> > > > > >
> > > > > > Also, we already have service invocation functionality for .Net
> > thick
> > > > > > client (see PlatformServices class). For .Net thick client there
> > are
> > > > two
> > > > > > types of operation related to service invocation: create a proxy
> > and
> > > > > invoke
> > > > > > a method (this approach is identical to java thick client).
> > > > > >
> > > > > > But I think we can't use two operations for thin clients. If we
> > > create
> > > > a
> > > > > > proxy by a separate operation we should store this resource
> > somewhere
> > > > on
> > > > > > server-side and we should also have an ability to close this
> > resource
> > > > > when
> > > > > > it's not needed anymore. So there is an additional operation on
> > > > > client-side
> > > > > > needed to close the proxy explicitly. This is more complex from
> > users
> > > > > point
> > > > > > of view than the current approach for java thick client, so I
> think
> > > > it's
> > > > > > better to use only one operation for thin clients:
> > OP_SERVICE_INVOKE
> > > > and
> > > > > > create a service proxy on each method invocation. In this case,
> > each
> > > > > > request should have at least these parameters: service name,
> > > interface
> > > > > > name, timeout, nodes set, method name, and args (sticky flag is
> > > useless
> > > > > > since we always will create a new proxy for each request).
> > > > > >
> > > > > > There is one more problem: methods of some interface can be
> > > overloaded.
> > > > > In
> > > > > > .Net thick client implementation there is a method used to find
> an
> > > > > > appropriate service method to invoke by method name and args
> > values:
> > > > > > PlatformServices.ServiceProxyHolder#getMethod. Since we use here
> > only
> > > > > args
> > > > > > values (don't have full information about args types) sometimes
> we
> > > can
> > > > > get
> > > > > > an error for overloaded methods. For example, if you have an
> > > interface
> > > > > > like:
> > > > > >
> > > > > > public interface TestServiceInterface {
> > > > > >     public String testMethod(String val);
> > > > > >     public String testMethod(Object val);
> > > > > > }
> > > > > >
> > > > > > And invoke service like:
> > > > > >
> > > > > > Object arg = null;
> > > > > > svc.testMethod(arg);
> > > > > >
> > > > > > Java will resolve the correct method to call on client-side, but
> > > using
> > > > > only
> > > > > > arg value (null) it's impossible to get exactly one method on the
> > > > > > server-side (PlatformServices.ServiceProxyHolder#getMethod will
> > throw
> > > > an
> > > > > > error in this case: Ambiguous proxy method 'testMethod')
> > > > > >
> > > > > > To solve this problem we can pass full method signature (method
> > name
> > > > with
> > > > > > parameters types) instead of just method name. Or we can
> > additionally
> > > > > pass
> > > > > > argument types to find exactly one method by
> Class.getMethod(String
> > > > name,
> > > > > > Class<?>... parameterTypes). Also, we can support two approaches
> at
> > > the
> > > > > > same time: just the method name to simplify the implementation of
> > > > > non-java
> > > > > > thin clients, and full method signature to deal with overloaded
> > > > methods.
> > > > > >
> > > > > > So,
> > > > > > What do you think about single operation for service invocation
> > > (create
> > > > > > service proxy on each invoke request)?
> > > > > > What do you think about ways to resolve the method?
> > > > > >
> > > > > > [1] :
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
> > > > > > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Plekhanov]

Hello,

I've benchmarked 1-operation approach vs 2-operations approach and
published benchmark results on IEP page [1]. It looks like performance
almost the same, so the single-operation approach should be implemented.

One more question: do we need some parameter on the server-side to disable
service invocations by thin client? Do we need to disable it by default?
I think the parameter will be useful, but I'm not sure about default value.
What do you think?

[1] :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation

ср, 20 мая 2020 г. в 14:50, Alex Plehanov <[hidden email]>:

> Pavel,
>
> I will try to benchmark by myself. Thank you.
>
> ср, 20 мая 2020 г. в 13:54, Pavel Tupitsyn <[hidden email]>:
>
>> Alex,
>>
>> Thank you, the IEP looks complete now.
>>
>> Are you going to do the comparison benchmark of 1-operation vs 2-operation
>> modes?
>> I can do that too, just want to avoid duplicate work.
>>
>> On Wed, May 20, 2020 at 1:17 PM Alex Plehanov <[hidden email]>
>> wrote:
>>
>> > Pavel,
>> >
>> > Yes, looks like we can get this information from ServiceDescriptor. I've
>> > removed 'interface name' from requests in IEP. Thank you!
>> >
>> > ср, 20 мая 2020 г. в 12:58, Pavel Tupitsyn <[hidden email]>:
>> >
>> > > Alex,
>> > >
>> > > IEP looks good to me in general.
>> > >
>> > > One question: what is `Interface name` in the request?
>> > > As I understand, service name is enough to retrieve ServiceDescriptor,
>> > > and then we can get serviceClass from there.
>> > >
>> > > On Wed, May 20, 2020 at 12:42 PM Alex Plehanov <
>> [hidden email]>
>> > > wrote:
>> > >
>> > > > Pavel,
>> > > >
>> > > > I've moved proposals from this thread to the IEP [1] and described
>> > > changes
>> > > > to protocol, please have a look.
>> > > >
>> > > > [1] :
>> > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
>> > > >
>> > > > пн, 18 мая 2020 г. в 15:09, Pavel Tupitsyn <[hidden email]>:
>> > > >
>> > > > > Hi Alex,
>> > > > >
>> > > > > Thanks for starting this thread.
>> > > > > I've created the IEP some time ago but then got distracted by
>> other
>> > > > things.
>> > > > >
>> > > > > My thoughts:
>> > > > >
>> > > > > *1. Create service proxy on each invoke request*
>> > > > > Single client operation is a lot simpler to implement on both
>> sides
>> > > > (client
>> > > > > and server), so I would prefer this way.
>> > > > > The only concern here is performance. My plan was to benchmark and
>> > then
>> > > > > decide.
>> > > > >
>> > > > > *2. Method resolution*
>> > > > > Taking Python and other dynamically typed languages into account,
>> > > > > current PlatformService implementation seems to be the best fit.
>> > > > >
>> > > > > If we decide to add an optional signature, we should not make it
>> > > > > Java-specific:
>> > > > > use binary type IDs (that are already part of the protocol) to
>> > specify
>> > > > > parameter types.
>> > > > >
>> > > > >
>> > > > > On Mon, May 18, 2020 at 2:27 PM Alex Plehanov <
>> > [hidden email]
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Hello Igniters,
>> > > > > >
>> > > > > > I have plans to implement service invocation in thin clients.
>> I've
>> > > > > already
>> > > > > > implemented a PoC for java thin client and want to discuss some
>> > > > details.
>> > > > > > Also, Pavel Tupitsin has created IEP [1] and the ticket for .Net
>> > thin
>> > > > > > client [2].
>> > > > > >
>> > > > > > To invoke the service method by java thick client we can get
>> > service
>> > > > > proxy
>> > > > > > by:
>> > > > > > IgniteServices.serviceProxy(String name, Class<? super T>
>> svcItf,
>> > > > boolean
>> > > > > > sticky, long timeout)
>> > > > > > and then invoke the method on this proxy.
>> > > > > >
>> > > > > > Also, we already have service invocation functionality for .Net
>> > thick
>> > > > > > client (see PlatformServices class). For .Net thick client there
>> > are
>> > > > two
>> > > > > > types of operation related to service invocation: create a proxy
>> > and
>> > > > > invoke
>> > > > > > a method (this approach is identical to java thick client).
>> > > > > >
>> > > > > > But I think we can't use two operations for thin clients. If we
>> > > create
>> > > > a
>> > > > > > proxy by a separate operation we should store this resource
>> > somewhere
>> > > > on
>> > > > > > server-side and we should also have an ability to close this
>> > resource
>> > > > > when
>> > > > > > it's not needed anymore. So there is an additional operation on
>> > > > > client-side
>> > > > > > needed to close the proxy explicitly. This is more complex from
>> > users
>> > > > > point
>> > > > > > of view than the current approach for java thick client, so I
>> think
>> > > > it's
>> > > > > > better to use only one operation for thin clients:
>> > OP_SERVICE_INVOKE
>> > > > and
>> > > > > > create a service proxy on each method invocation. In this case,
>> > each
>> > > > > > request should have at least these parameters: service name,
>> > > interface
>> > > > > > name, timeout, nodes set, method name, and args (sticky flag is
>> > > useless
>> > > > > > since we always will create a new proxy for each request).
>> > > > > >
>> > > > > > There is one more problem: methods of some interface can be
>> > > overloaded.
>> > > > > In
>> > > > > > .Net thick client implementation there is a method used to find
>> an
>> > > > > > appropriate service method to invoke by method name and args
>> > values:
>> > > > > > PlatformServices.ServiceProxyHolder#getMethod. Since we use here
>> > only
>> > > > > args
>> > > > > > values (don't have full information about args types) sometimes
>> we
>> > > can
>> > > > > get
>> > > > > > an error for overloaded methods. For example, if you have an
>> > > interface
>> > > > > > like:
>> > > > > >
>> > > > > > public interface TestServiceInterface {
>> > > > > >     public String testMethod(String val);
>> > > > > >     public String testMethod(Object val);
>> > > > > > }
>> > > > > >
>> > > > > > And invoke service like:
>> > > > > >
>> > > > > > Object arg = null;
>> > > > > > svc.testMethod(arg);
>> > > > > >
>> > > > > > Java will resolve the correct method to call on client-side, but
>> > > using
>> > > > > only
>> > > > > > arg value (null) it's impossible to get exactly one method on
>> the
>> > > > > > server-side (PlatformServices.ServiceProxyHolder#getMethod will
>> > throw
>> > > > an
>> > > > > > error in this case: Ambiguous proxy method 'testMethod')
>> > > > > >
>> > > > > > To solve this problem we can pass full method signature (method
>> > name
>> > > > with
>> > > > > > parameters types) instead of just method name. Or we can
>> > additionally
>> > > > > pass
>> > > > > > argument types to find exactly one method by
>> Class.getMethod(String
>> > > > name,
>> > > > > > Class<?>... parameterTypes). Also, we can support two
>> approaches at
>> > > the
>> > > > > > same time: just the method name to simplify the implementation
>> of
>> > > > > non-java
>> > > > > > thin clients, and full method signature to deal with overloaded
>> > > > methods.
>> > > > > >
>> > > > > > So,
>> > > > > > What do you think about single operation for service invocation
>> > > (create
>> > > > > > service proxy on each invoke request)?
>> > > > > > What do you think about ways to resolve the method?
>> > > > > >
>> > > > > > [1] :
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
>> > > > > > [2] : https://issues.apache.org/jira/browse/IGNITE-12754
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Alexey Goncharuk]

Alexey,

Hello,
>
> I've benchmarked 1-operation approach vs 2-operations approach and
> published benchmark results on IEP page [1]. It looks like performance
> almost the same, so the single-operation approach should be implemented.
>
Do I understand correctly that you suggest to remote
the OP_SERVICE_GET_PROXY request altogether given that the performance is
the same?


> One more question: do we need some parameter on the server-side to disable
> service invocations by thin client? Do we need to disable it by default?
> I think the parameter will be useful, but I'm not sure about default value.
> What do you think?
>
I do not think we need an additional flag for this, my thought is that it
should be ruled by appropriate security permissions.

[Alexey Plekhanov]

Alexey,

Yes, I've got almost the same performance (the difference is about 1%). I
think proxy creation has a relatively low cost compared to 2-4 network hops
required to invoke the service method.

More precisely:
First approach: create a service proxy on server-side each time, when a
service method is invoked by thin client (on each OP_SERVICE_INVOKE
request).
Second approach: create a service proxy by request (OP_SERVICE_GET_PROXY),
store it on server-side in resource map (ConcurrentHashMap), get it from
resource map each time when a service method is invoked (OP_SERVICE_INVOKE)

Only OP_SERVICE_INVOKE was used for benchmarking (OP_SERVICE_GET_PROXY was
used during the warmup phase)

Here are GitHub links to PoC implementations for both approaches ([1],
[2]). Benchmark
class: org.apache.ignite.yardstick.thin.service.IgniteThinServiceInvocationBenchmark

[1]: https://github.com/alex-plekhanov/ignite/tree/ignite-13033-bench-a1
[2]: https://github.com/alex-plekhanov/ignite/tree/ignite-13033-bench-a2


вт, 2 июн. 2020 г. в 17:16, Alexey Goncharuk <[hidden email]>:

> Alexey,
>
> Hello,
> >
> > I've benchmarked 1-operation approach vs 2-operations approach and
> > published benchmark results on IEP page [1]. It looks like performance
> > almost the same, so the single-operation approach should be implemented.
> >
> Do I understand correctly that you suggest to remote
> the OP_SERVICE_GET_PROXY request altogether given that the performance is
> the same?
>
>
> > One more question: do we need some parameter on the server-side to
> disable
> > service invocations by thin client? Do we need to disable it by default?
> > I think the parameter will be useful, but I'm not sure about default
> value.
> > What do you think?
> >
> I do not think we need an additional flag for this, my thought is that it
> should be ruled by appropriate security permissions.
>