On Wednesday, September 27, 2017 at 2:05:58 AM UTC-7, David Edery wrote: > > 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? >
I think so. > > 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 >> > 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/60e85987-5358-49fd-93ad-23e47aac5952%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
