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 <vlads...@gmail.com> wrote: > 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 direct service topology > version in the call responses should work faster if service is being > requested. Or you think this is not significant? > > > On 17.10.2023 11:13, Pavel Tupitsyn <ptupit...@apache.org> wrote: > > 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, Oct 16, 2023 at 8:17 PM Vladimir Steshin <vlads...@gmail.com> > wrote: > > > > > 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? > > > > > > > >
