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
