On Mon, Apr 17, 2017 at 10:16 PM, David Edery <da...@intuitionrobotics.com> wrote:
> ping :) > You didn't include me in the to: in your reply, so it got lost in the noise. > On Tuesday, April 4, 2017 at 9:14:45 AM UTC+3, David Edery wrote: >> >> On Friday, March 31, 2017 at 10:49:32 PM UTC+3, Eric Anderson wrote: >>> >>> On Mon, Mar 27, 2017 at 10:11 PM, David Edery < >>> da...@intuitionrobotics.com> wrote: >>>> >>>> A: >>>> So if I understand correctly (and please correct me if I'm wrong), once >>>> state API is available the flow would be something like: >>>> 1. create the channel (as described above) with idleTimeout + listener >>>> on connectivity state change >>>> 2. In case of connectivity state change, goto #1 >>>> 3. prior to using the channel, call getState(true) to eagerly connect >>>> it (in case that idleTimeout was reached) if is not connected and then do >>>> the actual streaming work >>>> >>> >>> #2 should be calling getState(true). #3 should never be necessary; >>> getState(true) basically does the first half of setting up an RPC, making >>> sure that a connection is available, but then doesn't send an RPC >>> >> >> Just to be sure that I understand the flow - for #2, when the >> connectivity state changes, I don't need to rebuild the whole channel I >> just need to call getState(true). Right? >> > Yes. There's another, probably-unrelated issue of a channel that reached the >> streaming limitation - If I stream more than 65 seconds using the same >> channel, I get an exception. I assume that the source of this exception is >> the speech API itself and not an internal gRPC logic (is my assumption >> correct?) Currently I'm handling this by: >> A. Not streaming more than 65 seconds of audio data >> B. Once I get the final result from the speech API, I immediately create >> another channel using the above described flow >> > I'd have to see the error to say. There's not any hard-coded limit of 65 seconds in grpc, but networks can do strange things at times. If you have to create a new channel, then than sounds like the network and not the speech API. If it was the speech API, I'd expect a failure but creating a new RPC on the Channel would work fine. If my assumption is correct, I guess that that's the way to avoid the >> exception. If not, is there a way to re-use the channel by calling a kind >> of "reset" function? (just like your suggestion above on #2 in which the >> channel should be reused by calling getState(true) instead of creating a >> new channel) >> > Any I/O error the channel experiences should automatically "reset" the channel. There should be no need to trigger something manually. -- 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/CA%2B4M1oPXOYUG9m1jXAMSCPBDk-SZ6p%2B%3DY1L-C%3D8rJD%2Bq%2BgEN1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
