--
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 post to this group, send email to grp...@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/0bc44915-5fed-4abe-babc-6dcab8b9ce91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
This functionality isn't supported or easily exposed in the open source gRPC Python implementation.I would recommend the approach you suggested and run the WSGI server in a separate thread.
On Thu, May 31, 2018 at 9:29 AM <zun...@humu.com> wrote:
--Hi everyone,I'm spinning up a new gRPC server in Python (3.6), and it would be very useful for me if the same binary could serve some other types of HTTP request as well -- /statusz-type requests as a simple example, but likely other things. (Having a single binary is valuable because then these requests could report on the active state of the server, without requiring that this be synchronized to some storage, multiple deployments, etc) We also already have a well-established stack for implementing WSGI servers in our org.One approach would be to have the main loop both spin up gRPC and run some WSGI server in a separate thread. (Are there any WSGI servers which are friendly to this kind of thing? Most use multiple processes) But that seems a bit wasteful, since cygrpc already has a really good HTTP server inside it that's polling in a fashion frankly better than most Python-compatible web servers do.Does anyone know if there is a way to access the underlying HTTP server within cygrpc or even gRPC itself -- essentially, to have HTTP requests which aren't part of some underlying RPC flow passed to a handler function instead of simply being dropped as an error?(This is very easy with the underlying Stubby code, of course, but I'm not sure how gRPC handles it and source-diving has proven uninformative so far...)Yonatan
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+unsubscribe@googlegroups.com.
Question about how people "usually" do this, then: if someone is running a gRPC server on GCE or app engine or the like, how does it answer health checks?
It's compatible with at least 1 other implementation already but there's more work to do.