Good idea, but the problem I have with this (if I understand you right) is that some of the server tasks are just these big monolithic calls that sit there doing CPU-intensive work (sometimes in a third-party library; it's not trivial to change them to stream back progress reports or anything).
So it feels like some way of running them in a separate thread and having an overseer method able to kill them if the client disconnects is the way to go. We're already using a ThreadPoolExecutor to run worker threads so I feel like there's something that can be done on that side... just seems like this ought to be a Really Common Problem, so I'm surprised it's either not directly addressed or at least commonly answered. On Monday, December 17, 2018 at 1:27:39 PM UTC-6, robert engels wrote: > > You can do this if you use the streaming protocol - that is the only way I > know to have any facilities to determine when a “client disconnects”. > > On Dec 17, 2018, at 1:24 PM, [email protected] <javascript:> wrote: > > I'm sure it's been answered before but I've searched for quite a while and > not found anything, so apologies: > > We're using python... we've got server tasks that can last quite a while > (minutes) and chew up lots of CPU. Right now we're using REST, and when/if > the client disconnects before return, the task keeps running on the server > side. This is unfortunate; it's costly (since the server may be using > for-pay services remotely, leaving the task running could cost the client) > and vulnerable (a malicious client could just start and immediately > disconnect hundreds of tasks and lock the server up for quite a while). > > I was hoping that a move to GRPC, in addition to solving other problems, > would provide a clean way to deal with this. But it's not immediately > obvious how to do so. I could see maybe manually starting a thread/Future > for the worker process and iterating sleeping until either the context is > invalid or the thread/future returns, but I feel like that's manually > hacking something that probably exists and I'm not understanding. Maybe > some sort of server interceptor? > > How would it be best to handle this? I'd like to handle both very long > unary calls and streaming calls in the same manner. > > Cheers, > Vic > > > -- > 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/9e84949d-139c-43df-a09e-5d8cc79022be%40googlegroups.com > > <https://groups.google.com/d/msgid/grpc-io/9e84949d-139c-43df-a09e-5d8cc79022be%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/90ba2085-8fb9-4851-9ae7-75ad45a5021d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
