Pavel,

I will try to benchmark by myself. Thank you.

ср, 20 мая 2020 г. в 13:54, Pavel Tupitsyn <ptupit...@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 <plehanov.a...@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 <ptupit...@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.a...@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 <ptupit...@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.a...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to