IgniteServices.serviceProxy and local services

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

IgniteServices.serviceProxy and local services

Denis Mekhanikov
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-
Reply | Threaded
Open this post in threaded view
|

RE: IgniteServices.serviceProxy and local services

Stanislav Lukyanov
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-