Injecting the RoD means that we are shutting down the server pipeline. If the server is shutting down, then we can't guarantee that a request submitted concurrently will be executed anyway, so clearing the queue of submitted requests (submitted but no preped for execution) sounds like correct behavior to me.
-Flavio > On 04 Oct 2015, at 23:05, Chris Nauroth <cnaur...@hortonworks.com> wrote: > > Hi Jordan, > > That's an interesting find. I think you have a good theory. Have you > already tried patching this to see if the bug reported against Curator > goes away? (BTW, is there a corresponding Curator JIRA?) > > That logic dates all the way back to the initial import of the codebase. > I can't find a definitive explanation, but my best guess is that dropping > pending requests (instead of gracefully quiescing) can give a faster > shutdown in the event of a heavily overloaded server. However, the > correctness of this choice looks questionable, especially in stand-alone > mode where you don't have a cluster of other machines to compensate. > > Something else interesting is that this doesn't even really guarantee that > the request of death is the only thing remaining to be processed. There > is no synchronization over the queue covering both the clear and the > enqueue of the request of death, so I think there is a window in which > other requests could trickle in ahead of the request of death. > > --Chris Nauroth > > > > > On 10/1/15, 8:21 PM, "Jordan Zimmerman" <jord...@bluejeansnet.com> wrote: > >> Why does PrepRequestProcessor.shutdown() call submittedRequests.clear(); >> before adding the death request? What if there are pending requests? I¹m >> trying to track down a bug reported in Curator. It only happens in >> Standalone ZK instances. From what I can tell, shutting down a standalone >> instance might result in lost transactions. Am I looking down the wrong >> path or is this a possibility? >> >> -Jordan >
