Hi Igniters! I propose to add the /service awareness feature to the thin
client/. I remember a couple of users asked of it. Looks nice to have
and simple to implement. Similar to the partition awareness.
Reason:
A service can be deployed only on one or few nodes. Currently, the thin
client chooses one or a random node to invoke a service. Then, the
service call can be always or often redirected to other server node. I
think we would need: - Bring a new feature to the thin client protocol
(no protocol version change). - Require the partition awareness flag
enabled (it creates required connections to the cluster). - Transfer the
service topology in the service call response (server node /already
holds /needed service topology).
- Keep the service topology in the client service proxy. If that is ok,
my question is /how to update service topology on the client/?
I see the options: 1) Add a version to the service topology on the
server node and on the client service proxy. Add actual service topology
to the service call response if actual>client.
/Pros/: Always most actual service top. version
/Cons/: Requires holding and syncing top. version on server nodes only
for the thin clients.
2) Add the actual service topology to the service call response only if
service is not deployed on the current node. The client invalidates
received service topology every N invocations and/or every N seconds
(/code constants/).
/Pros/: Simple.
/Cons/: Actual topology delays. Not the best load balancing.
3) Send from client a hash for the known service nodes UUIDs in every
service call request. Add actual service topology to the service call
response if the server's hash is not equal.
/Pros/: Simple. Always most actual service topology.
/Cons/: Costs some CPU sometimes.
WDYT?
