On Oct 17, 2018, at 2:06 PM, robert engels <[email protected]> wrote:
> Ok, so my original statement about being forced to use the ‘streaming rpc’ > was the correct way. I thought you said that was the case, but then you > offered up what seemed like other solutions that would allow me to use > individual rpcs… > You said you were forced to use streaming because of some specific reasons. I tried to correct some specific incorrect understanding, namely that "a new connection (tcp) is made for each request" is incorrect. You also asked about connection lifecycle notifications, but it is unclear what for. I think part of the problem is it's not really clear to me what semantics you're looking for in "stable connection." It's in quotes and can be interpreted a few different ways. It sounds like you may be wanting to use streaming since it provides a lifetime. For example, if you were wanting to implement a transaction, a stream could be a quite nice approach. The stream provides a "context" for all the messages while also providing a lifetime for the transaction; if the RPC is cancelled the transaction could be aborted. I'm sorry, but I wasn't trying to say you should or shouldn't use streaming. I was only trying to inform the constraints that may cause you to choose streaming. But then why have the ‘idle time’ - if the connections are terminated when > there are not more rpcs ? I am not sure why the server process can’t be > notified when a connection is “terminated” due to idle timeout (or any > other reason - like IO errors) - so it can clean up cached resources - > doesn’t make a lot of sense to me? On Wed, Oct 17, 2018 at 12:07 PM robert engels <[email protected]> wrote: > Sorry, meaning, that I need to add my own ‘idle timeout’ on the server > application level to basically accomplish the same thing that the rpc > connection is already doing… > If you will be using a single stream for all the data, then yes, you may want to close it after an idle period. You may even want to close it after a certain lifetime (this is useful for re-distributing load across multiple backends, for instance). I don't know what you are trying to do well enough to understand what you are wanting to do with the connection notification. I will say that for gRPC, we make no association between a "client" and a "connection." A single client can have more than one connection to the same backend (this can happen normally due to GOAWAY, but also possibly with client-side load balancing) and a single connection to a backend can have multiple clients (in the case of an L7/HTTP proxy). -- 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%2B4M1oP5_%3D%2BcyLDLh7Nxb%2B%3D4hvS21CMSb7eog5Y-z9tWoAjH_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
