Reviving this thread. Hi, I see that https://github.com/grpc/grpc-java/issues/2292 was marked as closed a week ago. Does this concludes the issue of (in short) "understanding the state of the channel and act according"? (the details are in the thread of course)
Addressing your last comment in this post "It's currently scheduled for Q2" (see below) - is this the change you were referring? Thanks, David. On Monday, March 27, 2017 at 7:19:38 PM UTC+3, Eric Anderson wrote: > > On Sun, Mar 26, 2017 at 9:28 AM, David Edery <da...@intuitionrobotics.com > <javascript:>> wrote: > >> 500ms is too much for my app to wait before streaming. This is why I >> prepare everything before and I make sure that at the end of a recognition >> operation the full structure is prepared for the next iteration. > > > ManagedChannel connects lazily (on first RPC), and I'd expect a good > portion of the 500ms is creating the TCP connection and TLS. Eagerly > connecting will be provided by the channel state API via getState(true). > > >> However, I've noticed that given a long enough idle wait (don't know how >> long, matter of minutes) of the channel, if I try to stream the audio, >> everything acts as if all is well but I don't get any response (to >> beginning of speech nor transcripts nor any error). >> > > That sounds like a network failure. Once we support keepalive without any > active RPCs (I'm working on this now; is about a week away; it may make the > next release), it could detect the failure. But using that option with > Google APIs is unsupported; the frontend doesn't want the additional > traffic. At the moment we would suggest using > ManagedChannelBuilder.idleTimeout > <http://www.grpc.io/grpc-java/javadoc/io/grpc/ManagedChannelBuilder.html#idleTimeout-long-java.util.concurrent.TimeUnit-> > so > that the TCP connection is torn down during the inactive period so that it > isn't in a hung state when you want to do an RPC. > > I hypothesised that it has to do with the connectivity state/idle state of >> the channel and decided that I'll constantly shut the channel down and >> reconnect in 1 minute intervals (given of course that it's not busy). This >> solved the problem - but it's a workaround of course. >> > > I don't think the issue is caused by a gRPC state change. It's generally > caused by problems in the network. Using idleTimeout() will trigger gRPC to > shutdown the connection for you. In order to avoid the 500ms overhead > later, you'd need the channel state API and ask the channel to re-connect > each time it goes IDLE. > > Is there a way to know what's the state of the channel? I saw that >> grpc-java issue #28 should address this issue with the >> ManagedChannel.getState/notifyWhenStateChanged APIs (rel 1.2.0) but it's >> not implemented yet. >> > > Nope. Note that the API wouldn't tell you anything in this case, since the > problem isn't likely caused by gRPC going idle. But if it was implemented > it would provide you a way to "kick" gRPC to eagerly make a TCP connection. > > I also saw that there's a health check protocol ( >> https://github.com/grpc/grpc/blob/master/doc/health-checking.md) - does >> this feature work? would it be suitable for my needs? >> > > That's more for load balancing (avoiding backends that aren't healthy). It > wouldn't help you, as I don't think our public APIs provide such a service. > > When is the state API is expected to land? I think that going forward this >> is the way to go from our app's perspective. >> > > It's currently scheduled for Q2. That isn't a promise, but gives an idea. > -- 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/5905660c-0f49-4c89-94a4-f1e7e1e5ca50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
