Load balancing policy question.

[solomon lifshits]

Hello, I am interested in the following behavior:

Is it possible to create a per-connection load balancing? In other words create a stub on the client side, so that dns resolution will be performed only on stub creation and all rpc calls on that stub will be invoked on the same grpc server?

I see that there are two load balancing policies available: round_robin and pick_first.

If I use "round_robin" I see that it implements a per-call balancing and different rpc calls on the same stub are resolved to different grpc server.

If I use "pick_first"(the default as far as I see), all the rpc calls on the same stub will go to the same server, which is good, but  from what I understand every subsequently created channel will also be resolved to the same server as soon as it is responsive.

Any thoughts on how I can achieve that? Thank you in advance.

[Eric Anderson]

Is it possible to create a per-connection load balancing? In other words create a stub on the client side, so that dns resolution will be performed only on stub creation and all rpc calls on that stub will be invoked on the same grpc server?

In general, no, there isn't one that does this, although I guess you could create one yourself. It is asking to cause outages it seems, though. What is your actual goal/use-case?

If I use "pick_first"(the default as far as I see), all the rpc calls on the same stub will go to the same server, which is good, but  from what I understand every subsequently created channel will also be resolved to the same server as soon as it is responsive.

Yes, pick_first is the default. Each time a connection needs to be made it will iterate through the address list (only one at a time) and the first address to successfully connect is used. When that connection is no longer available or if the addresses change (and the existing connection's address is no longer present) the process will be repeated.

I don't really understand what you meant by "subsequently created channel will also be resolved to the same server as soon as it is responsive." You won't re-create the Channel for a stub. If you meant connection (like TCP), then it is not guaranteed to resolve to the same server.

[solomon lifshits]

What I meant by subsequently created channel is: does every call for CreateChannel/CreateCustomChannel perform an explicit DNS lookup, or subsequent  call may reuse a cached result of  successful resolution from the previous one?

My grpc service has 2 rpc methods. I want to be able to have multiple stubs, so all the rpc calls on the same stub are resolved to the same endpoint grpc server. But each stub is "connected" to a different endpoint. 

Thanks!

[Eric Anderson]

What I meant by subsequently created channel is: does every call for CreateChannel/CreateCustomChannel perform an explicit DNS lookup, or subsequent  call may reuse a cached result of  successful resolution from the previous one?

Each channel does its own DNS lookup. Granted, the DNS lookup may be cached in the OS, but it may not as well.

My grpc service has 2 rpc methods. I want to be able to have multiple stubs, so all the rpc calls on the same stub are resolved to the same endpoint grpc server. But each stub is "connected" to a different endpoint.

There will be nothing that guarantees each stub will be on a different endpoint. I strongly suggest you explain your higher-level objective. What are you trying to achieve?