IDIEP-112
Author
Sponsor
Created 25.10.2023
Status
DRAFT


Motivation

The thin client invokes the service grid on a random server node. A service may not be deployed on each node. If node misses the invoked service, the invocation request is redirected to a proper node. Such redirection costs.

Description

There already is a similar feature - Partition Awareness. When enabled, the client calls exactly the primary node to update cache by key.

To achieve Service Awareness we should:
1) Bring a new feature to the thin client protocol.
2) Require and activate with the Partition Awareness flag enabled. It raises proper cluster connections.
3) Obtain service topology with a dedicated request by the client and provide it to the service proxies.
4) Initiate the topology update with: first service invocation, cluster topology change, some timeout (only if service is invoked).

New protocol feature

Minimal client protocol version1.7.0
The new protocol featureSERVICE_TOPOLOGY = 16

Service topology request

One new client operation is required:

NameCode
OP_SERVICE_GET_TOPOLOGY7003

OP_SERVICE_GET_TOPOLOGY message format

Request
StringService name
Response
intNumber of the following nodes UUIDs
UUID * countUUID of node with at least one service instance

Risks and Assumptions

 - Some delay of the topology obtaining. The invocation redirects are still possible when service migrates.
 - No sign of service cancel/deploy on the client side. We have to update by a timeout too.
 - The topology is probably kept by client while it exists even if the service proxy is not in use any more or if service was canceled.

Discussion Links

https://lists.apache.org/thread/vd0wnwxrg89245kv1nzolfb82j1l7z0t

Tickets

Java Thin Client implementation

Unable to render Jira issues macro, execution error.

  • No labels