The server doesn't really know what's going on from the client perspective, and even if we could detect a failed client, not all application-level thrift server implementations could actually be interrupted sanely. If you really want to achieve this kind of behavior you're going to end up writing a lot of crazy synchronization code, I think.
On Thu, Jan 5, 2012 at 6:20 PM, T Vinod Gupta <[email protected]> wrote: > hi, > for a long running request, thrift client can timeout and abort the api > call to the server. in that case, it doesnt make sense for the server to > keep working since the client is gone. > > are there any best practices/suggestions to deal with this kind of > scenarios? > > thanks > vinod >
