Pavel, I will try to benchmark by myself. Thank you.
ср, 20 мая 2020 г. в 13:54, Pavel Tupitsyn <[email protected]>: > 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 <[email protected]> > 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 <[email protected]>: > > > > > 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 < > [email protected]> > > > 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 <[email protected]>: > > > > > > > > > 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 < > > [email protected] > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
