Folks,
Currently IgniteServices.serviceProxy(...) [1] method is designed to return a locally deployed service if it's available. The remote services will be considered only if current one doesn't have the needed service locally. This behaviour breaks the load-balancing feature of services. Let's say we have ten nodes and a node singleton service, which is deployed on all of these ten nodes. And we have an endpoint on one of the nodes, that provides API of this service for external users. If we arrange things this way, all service method invocations will be routed to the local node, which will do all the work, while other 9 will be just chilling. If the "local-first" optimization weren't applied, then work would be evenly balanced between nodes. For those who want a local service instance we have an IgniteServices.service(...) [2] method. So, you can check it first, and if you get null from it, then get a proxy for a remote instance. Such change will change the public contract though. So, we need another method for service proxy acquisition. Something like *serviceProxy(String name, Class<? super T> svcItf, boolean sticky, boolean localFirst)* The contract of the existing method can be changed in Ignite 3.0 What do you think? Denis [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteServices.html#serviceProxy-java.lang.String-java.lang.Class-boolean- [2] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteServices.html#service-java.lang.String- |
I don’t think we should change the existing method contract – localFirst=true as a default looks OK.
But a new method that allows to change that to localFirst=false is nice. Checking service() for a local service first is not that great when your proxy isn’t sticky. You may want to have a non-sticky proxy that obtains a local service first, falls back to a remote service if local isn’t available, but may return to the local one on the next call if the service was deployed locally since then. My 2 cents, Stan From: Denis Mekhanikov Sent: 6 февраля 2019 г. 11:30 To: [hidden email] Subject: IgniteServices.serviceProxy and local services Folks, Currently IgniteServices.serviceProxy(...) [1] method is designed to return a locally deployed service if it's available. The remote services will be considered only if current one doesn't have the needed service locally. This behaviour breaks the load-balancing feature of services. Let's say we have ten nodes and a node singleton service, which is deployed on all of these ten nodes. And we have an endpoint on one of the nodes, that provides API of this service for external users. If we arrange things this way, all service method invocations will be routed to the local node, which will do all the work, while other 9 will be just chilling. If the "local-first" optimization weren't applied, then work would be evenly balanced between nodes. For those who want a local service instance we have an IgniteServices.service(...) [2] method. So, you can check it first, and if you get null from it, then get a proxy for a remote instance. Such change will change the public contract though. So, we need another method for service proxy acquisition. Something like *serviceProxy(String name, Class<? super T> svcItf, boolean sticky, boolean localFirst)* The contract of the existing method can be changed in Ignite 3.0 What do you think? Denis [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteServices.html#serviceProxy-java.lang.String-java.lang.Class-boolean- [2] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteServices.html#service-java.lang.String- |
Free forum by Nabble | Edit this page |