ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Lukyanov <stanlukya...@gmail.com>
Subject RE: IgniteServices.serviceProxy and local services
Date Wed, 06 Feb 2019 11:15:06 GMT
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

My 2 cents,

From: Denis Mekhanikov
Sent: 6 февраля 2019 г. 11:30
To: dev@ignite.apache.org
Subject: IgniteServices.serviceProxy and local services


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

The contract of the existing method can be changed in Ignite 3.0

What do you think?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message