You suggested that it is a bug, and I'm arguing that it isn't a bug. You may want to optimize and still process the requests in the queue before injecting RoD, but discarding them doesn't sound like a bug because you can't guarantee that requests submitted concurrently with the server shutting down will be executed. Optimizing isn't the same as spotting a bug. Also, if you are trying to shut down, you probably want to do it asap, rather than wait for a whole batch of operations to complete.
-Flavio > On 05 Oct 2015, at 14:57, Jordan Zimmerman <jor...@jordanzimmerman.com> wrote: > > Flavio, that isn’t logical. Just because you can’t make that guarantee > doesn’t imply that you should flush already queued transactions. > > -JZ > >> On Oct 5, 2015, at 3:24 AM, Flavio Junqueira <f...@apache.org> wrote: >> >> 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 >>> >> >
