Re: IEP-46 Thin client - Service invocation

[Alex Plehanov <pl...@gmail.com>]

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 <pl...@gmail.com>:

> Pavel,
>
> I will try to benchmark by myself. Thank you.
>
> ср, 20 мая 2020 г. в 13:54, Pavel Tupitsyn <pt...@apache.org>:
>
>> 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 <pl...@gmail.com>
>> 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 <pt...@apache.org>:
>> >
>> > > 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 <
>> plehanov.alex@gmail.com>
>> > > 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 <pt...@apache.org>:
>> > > >
>> > > > > 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 <
>> > plehanov.alex@gmail.com
>> > > >
>> > > > > 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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: IEP-46 Thin client - Service invocation

[Alex Plehanov <pl...@gmail.com>]

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 <al...@gmail.com>:

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

Re: IEP-46 Thin client - Service invocation

[Alexey Goncharuk <al...@gmail.com>]

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.