Sure:
IEP :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-112+Thin+Client+Service+Awareness
Ticket: https://issues.apache.org/jira/browse/IGNITE-20656
On 26.10.2023 18:15, Pavel Tupitsyn wrote:
Vladimir, could you please share the new IEP link here, and also link it to
the
Vladimir, could you please share the new IEP link here, and also link it to
the ticket?
On Thu, Oct 26, 2023 at 1:30 PM Vladimir Steshin wrote:
> Roman, hi.
>
> Done. Thanks!
>
> On 26.10.2023 13:25, Roman Puchkovskiy wrote:
> > Hi Vladimir. Sorry to intervene, but we have a clash with IEP
Roman, hi.
Done. Thanks!
On 26.10.2023 13:25, Roman Puchkovskiy wrote:
Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers,
there is already IEP-110 in Ignite 3, it was created on August, 1:
Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers,
there is already IEP-110 in Ignite 3, it was created on August, 1:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes
Is it possible to pick another number, while your
All right. Pavel, thank you.
IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110+Thin+Client+Service+Awareness
Ticket: https://issues.apache.org/jira/browse/IGNITE-20656
On 25.10.2023 11:04, Pavel Tupitsyn wrote:
Looks good to me
On Tue, Oct 24, 2023 at 1:50 PM Vladimir
Looks good to me
On Tue, Oct 24, 2023 at 1:50 PM Vladimir Steshin wrote:
> We've privately discussed with Mikhail Petrov and Alexey Plekhanov.
> To us, #2 seems OK with the exceptions that a dedicated request would be
> better for transferring the service topology. And it should be
We've privately discussed with Mikhail Petrov and Alexey Plekhanov.
To us, #2 seems OK with the exceptions that a dedicated request would be
better for transferring the service topology. And it should be processed
by the client instead of every service proxy.
So, the suggested solution
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, 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,
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
14 matches
Mail list logo
