Is there have "Resolver" and "Balancer" interface in Python ?

30 views
Skip to first unread message

stefan lei

unread,
Nov 8, 2020, 10:53:25 PM11/8/20
to grpc.io
Hello guys.

I found "Resolver" and "Balancer" in Java and Go,  Is there have in  Python ?
If not , How can I do ?  I am plan to use them with zookeeper , as  Service Found 

Can I build custom c-core version  for Python ?

Srini Polavarapu

unread,
Nov 11, 2020, 2:37:19 PM11/11/20
to grpc.io
Unfortunately, no. This is a long pending item that is resource starved. See https://github.com/grpc/grpc/pull/16617 and https://github.com/grpc/grpc/issues/11685.

Mark D. Roth

unread,
Nov 11, 2020, 2:48:11 PM11/11/20
to Srini Polavarapu, grpc.io
There are two parts to this question: the resolver API and the LB policy API.  I'll answer both separately.

For the LB policy API:
  • We currently have no plan to ever expose the ability to implement new LB policies in wrapped languages.  The reason for this is that the LB policy is on our critical performance path: it actually gets invoked at least once for each individual RPC.  It would basically kill performance to hop out of C-core and up into the wrapped language layer and then back into core for every individual RPC, so we don't think this is feasible.
  • That having been said, we would like at some point to provide a stable C++ LB policy API, so that new LB policies can be written in C++ and plugged directly into C-core, at which point they would work for any wrapped language.  However, this work is currently blocked on the EventManager work, since we can't expose our current API without exposing a bunch of our current ugly polling subsystem, which we don't want to expose as a public API.
For the resolver API:
  • Unlike the LB policy API, the resolver API is not performance-critical, and we do want to eventually expose a public API in wrapped languages for implementing new resolvers.   This will require first adding a new API to the C-core API to allow a resolver plugin to be injected from the wrapped language layer and then implementing an idiomatic API on top of that in each wrapped language.
  • The links that Srini provided reflect the current state of this.  I don't think there's anything preventing this from moving forward, except that no one has had time to work on it.
I hope this information is helpful.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3d95d058-ab2d-419d-b6d2-c745828f53d1n%40googlegroups.com.


--
Mark D. Roth <ro...@google.com>
Software Engineer
Google, Inc.
Reply all
Reply to author
Forward
0 new messages