They barely can guarantee. If client miss service instance node,
the request is just redirected. But I talk about the most reliable way
to keep actual service topology. If we watch cluster topology change
event, we have to take in account cases like:
- Client request service, gets its
None of the described approaches provides 100% guarantee of hitting the
primary node in all conditions.
And it is fine to miss a few requests. I don't see a reason to increase
complexity trying to optimize a rare use case.
On Tue, Oct 17, 2023 at 2:49 PM wrote:
> What if topology change event
What if topology change event preceedes service redeployment and service
mapping change? There a possibility for client to save new topology version
before services are actually redeployed. If we rely on actual change of the
service mapping (redeployment), there is no such problem.
On
I think if it's good enough for cache partition awareness, then it's good
enough for services. Topology changes are not that frequent.
On Tue, Oct 17, 2023 at 12:22 PM wrote:
> Hi, Pavel.
>
> 1. Correct.
> 2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag and sends
> additional
Hi all,
Please review "IEP-111: Ignite 3. Basic Multi-Statement Support” proposal. The
main purpose of this document is to state behavior of script processing from
the user's point of view.
https://cwiki.apache.org/confluence/display/IGNITE/IEP-111%3A+Ignite+3.+Basic+Multi-Statement+Support
Hi, Pavel.
1. Correct.
2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag and sends
additional ClientOperation.CLUSTER_GROUP_GET_NODE_ENDPOINTS to get new cluster
topology. Thus, the topology updates with some delay. We could watch this event
somehow in the service proxy. But
Hi Vladimir,
1. A topology of a deployed service can change only when the cluster
topology changes.
2. We already have a topology change flag in every server response.
Therefore, the client can request the topology once per service, and
refresh it when cluster topology changes, right?
On Mon,
