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