I have a project with a nearly identical use case to yours. It sounds like you used Zookeeper to implement your centralized state management and provide your forwarding table. I was curious if there were any other broadcast-type mechanisms available within the gRPC framework to avoid the need for a centralized state store. Ideally, each service node would broadcast the jobs they were capable of servicing to other nodes and each node would maintain knowledge of the others in-memory.
Anyone aware of something like that? On Tuesday, December 19, 2017 at 9:57:21 PM UTC-5, matt.m...@lucidworks.com wrote: > > Thanks everyone. We ended up going with the last suggestion, which was to > have this all be handled in a service. Working great. > > And btw, we're also using the Proxy you created, Eric. Slightly different > use case for us (no need to inspect the metadata) and is working great. Do > you plan on having this go into gRPC eventually? > > Thanks, > Matt > > On Friday, December 15, 2017 at 11:00:58 AM UTC-5, Eric Anderson wrote: >> >> On Fri, Dec 8, 2017 at 6:26 AM, <matt.m...@lucidworks.com> wrote: >> >>> I'm trying to find examples for how I can achieve a conditional >>> forwarding interceptor, on the server. >>> >> >> The conditional aspect of an interceptor should be trivial, as you should >> just use an if in your interceptor. >> >> "Forwarding" here sounds like you want to forward to another server (vs >> forwarding in-process to a different object). In general, this case seems >> simple enough you should just write the code as a normal service, and have >> the service issue a gRPC request to the correct backend. No fancy business, >> other than propagating the "no forwarding" bit to your service via >> Contexts.interceptCall(...). >> >> The only time I'd have expected to use an interceptor here is if you were >> wanting to do this logic on client-side using a client interceptor. >> >> I did write the beginnings of an example >> <https://github.com/ejona86/grpc-java/commit/29728aeb003ced3c190197c176563643be22bef1> >> >> (it's not merged, but functional) that does "forwarding" in the proxy >> sense. But it wouldn't be easy to use in your case since you want to >> parse/process the request message to determine where to forward to. Generic >> proxies would tend to use only Metadata for routing. Service-specific >> proxies should generally just write a service that behaves how they want. >> > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3f3a1349-477f-46f1-9674-3b18e4e255be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
