Hi Yang, Sorry for the delayed reply. I was on vacation.
Let me restate the problem very simply - Currently, I can't call grpc::Server::Shutdown without first making sure that all the "operations" are completed first but without calling grpc::Server::Shutdown, the server keeps sending me work from if client(s) keep requesting new rpc execution. The details of my setup are in my earlier reply. If I am missing something in the current api that can be used, please let me know. In fact, this recent post has the shutdown flow that I really want in Java - https://groups.google.com/forum/#!topic/grpc-io/P5BFGoGxkbw Some more information on this gRFC discussion that I shared privately previously (Just in case someone else also has inputs here). >> I create an encapsulation for Rpc object that will have it’s method executed in response to the events. The object contains a ServerContext which is naturally destroyed when the Rpc object goes out of scope. The Rpc object is destroyed when the aysnc done event from grpc is received. All the rpcs also queue up their ‘request’ event in completion queue. When my application wants to shutdown, I call the server shutdown routine followed by a completion queue shutdown. During this processing, the ‘done’ tag is received for queued up rpcs and rpcs in process. There is no other way for receiving the ‘done’ tag for these rpcs. So my Rpc object is destroyed in parallel. It should also be noted that grpc can send a “done” event for an rpc while an async op for the same rpc is waiting. So when I receive the done tag, I wait for the other async ops to finish for the object. Once I know that everything is cleaned up, I go ahead and destroy. << On Friday, December 22, 2017 at 1:22:41 PM UTC-8, Yang Gao wrote: > > Hi Arpit, > > You did not mention you use grpc_init() before. My understanding of the > crash you saw at the destruction of ServerContext is that you have no more > grpc_init() covering at that point. And you deleted the server before > destroying the ServerContext (rather than just shutdown the server). > If that is not the case, then I think my previous thought was not right. > > > > On Wed, Dec 20, 2017 at 11:33 AM, Arpit Baldeva <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I have looked at the gRFC and not too sure how it fixes some of the >> current issues with library shutdown (you referenced the issues I mentioned >> on GitHub/private conversations). >> >> First off, I don't know about other users but I was already forced to use >> grpc_init/shutdown in my code (so I am aware of those functions). In my >> app, I am setting the tracers using tracer api and the tracers are only >> enabled if the grpc_init is called first. So when the application boots up >> and I configure my logging, I needed to call grpc_init before doing >> anything with server instantiation etc. >> >> The main problem I have is I feel like the current apis require too much >> management from the integrator and still not 100% safe. >> >> >> >> In my setup, I use async api. My main thread processes events/tags while >> I have a separate thread to pump the completion queue. Now, suppose I want >> to shutdown my server instance. Currently, I can’t call >> grpc::Server::Shutdown without making sure that all my existing events in >> progress are finished first and I have destroyed every reference to all the >> library objects (say ServerContext which theoretically should be >> independent of server life time) . However, without calling >> grpc::Server::Shutdown, my server may keep on getting new events from new >> clients requesting new rpcs. It’d be much easier if I had an api that could >> allow me to cancel pending rpcs (the ones that have not been started yet). >> At the moment, only way for me to do this would be to keep a list of rpcs >> that have not started and manually call serverContext->TryCancel on them. >> >> >> Are you suggesting that with new flow, I can simply call >> grpc::server::Shutdown, have it cancel all the pending rpcs/events (some of >> which can cause freeing of additional resources like ServerContext) and the >> things that are attaching their lifetime to server would instead hang on to >> the GrpcLibrary? >> >> >> Thanks. >> >> >> On Tuesday, December 19, 2017 at 3:48:40 PM UTC-8, Yang Gao wrote: >>> >>> Users reported bugs related to this issue. Some of the issues can be >>> avoided/worked around by strengthening the requirement or minor tweaks of >>> the code. >>> Some are not so easy to fix without potential performance overhead. The >>> internal doc contains a couple of more links of related issues people >>> encountered. >>> >>> On Tue, Dec 19, 2017 at 3:24 PM, 'Vijay Pai' via grpc.io < >>> [email protected]> wrote: >>> >>>> Hi there, >>>> >>>> I'd very much like to discuss this issue. Switching to explicit >>>> initialization increases friction for users, but keeping it the existing >>>> way just increases friction for the library writers (unless the code ends >>>> up being so failure-prone that it affects users through a loss of >>>> stability). Has there been a user feature request for explicit >>>> initialization? >>>> >>>> >>>> On Tuesday, December 12, 2017 at 9:40:21 AM UTC-8, Yang Gao wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have created a gRFC in https://github.com/grpc/proposal/pull/48 >>>>> which will add a new C++ class to make gRPC C++ library lifetime explicit. >>>>> If you have comments and suggestions, please use this thread to >>>>> discuss. >>>>> Thanks. >>>>> >>>> -- >>>> 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/79d883f9-cbc3-4281-9c16-3f5b7edaff3e%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/79d883f9-cbc3-4281-9c16-3f5b7edaff3e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/fd79a64c-048a-4dd5-9d2b-ae7256009e40%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/fd79a64c-048a-4dd5-9d2b-ae7256009e40%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/2800cf47-1077-4125-ac22-9b7e52daabf0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
