On Mon, Mar 27, 2017 at 10:11 PM, David Edery <[email protected]> wrote:
> 4. Create a request observer (of type > StreamObserver<StreamingRecognizeRequest>) > by calling the speech client's (which is of type SpeechGrpc.SpeechStub) > streamingRecognize function > > I didn't get into the details (yet) but I'm sure that there's network > activity in the above described flow. I know it due to an exception I got > on network activity when this flow was executed on the main (UI) thread > (which doesn't allow network activity to be executed on it). > #4 creates an RPC. So that's where the I/O should be. "the frontend doesn't want the addition traffic" == RPC calls are ok but > anything else would be suspected as DDoS? (depends of course on the > frequency of the keep alive) > I can't speak authoritatively, but I think it more about the load and lack of billing. If you aren't careful, keepalive pings can very easily eat up a significant portion of network/cpu. They are also mostly invisible, so it's very easy to avoid noticing unnecessary load. 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. >> > > 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 B: > Today, in step #1 (that doesn't include idleTimeout), if channel != null > && !channel.isShutdown && !channel.isTerminated I call channel.shutdownNow > and immediately create a new ManagedChannel (which means - the way I > understand it - that there's a channel in the process of shutting down > while immediately I create another channel which is wiring up). Just to > validate this point - is this described flow is ok? (shutdown one channel > instance while creating another channel for the same host). > Shutting down a channel while creating another to the same host is safe. I probably would just check isShutdown; isTerminated can take some time since it needs to release resources. Semi-unrelated, but isTerminated == true implies isShutdown == true. Given the future A and the current B, I assume that I will still need to > take care for the channel shutdown at the end of the streaming operation. > idleTimeout will not take care for it once the channel has been active no? > from the documentation of idleTimeout: "By default the channel will never > go to idle mode after it leaves the initial idle mode". Is this a correct > assumption? > Does the above flow (A+B) sounds reasonable as a solution to an > always-ready channel requirement? > Hmm... that documentation is bit misleading. I just sent out a PR to improve it <https://github.com/grpc/grpc-java/pull/2870>. idleTimeout doesn't shutdown a channel, but it would cause it to go idle (i.e., TCP connection). The part of documentation you linked to starts with "by default"; that was meaning "if you don't call idleTimeout." -- 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 [email protected]. To post to this group, send email to [email protected]. 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%2B4M1oP2iAhotcnMa%3D8c1%3DT2NfTAhyeyscawPvDwDB-41TJPXg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
