Looks good to me On Tue, Oct 24, 2023 at 1:50 PM Vladimir Steshin <vlads...@gmail.com> 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 processed > by the client instead of every service proxy. > > So, the suggested solution is: > 1) Bring a new feature to the thin client protocol. > 2) Require the partition awareness flag enabled. > 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). > > Cons: > - 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 is > not in use any more. > > If the suggestion looks reasonable, I'm ready to implement, create IEP. > > On 17.10.2023 18:28, Vladimir Steshin wrote: > > > > 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 topology > > > > - The service is canceled and redeployed to another nodes. No cluster > > topology change, no sign of it on the client side. > > > > - Client continue service requesting and misses instance node forever > > or often. > > > > If we provide, for example, version or hash of client topology version > > in every service call request, we always get actual service topology > > just by comparing on server side. Independently of why and when > > service redeploys. Isn't it simple and safe? > > > > On 17.10.2023 15:52, Pavel Tupitsyn wrote: > >> 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<vlads...@gmail.com> wrote: > >> > >>> 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 17.10.2023 13:44, Pavel Tupitsyn<ptupit...@apache.org> wrote: > >>>> 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? > >>>>>>>
