[GitHub] [accumulo] ctubbsii edited a comment on issue #1689: Tserver in bad state may be writing corrupted files during compactions.

[GitBox <gi...@apache.org>]

ctubbsii edited a comment on issue #1689:
URL: https://github.com/apache/accumulo/issues/1689#issuecomment-694603973


   @EdColeman Thanks for the code in #1709. I get the gist of what you're proposing as a solution (to it's own lock and self-terminate). But, I still don't understand the problem from the above description. You said there's a `NullPointerException` being thrown, but it's not possible for it to be thrown in the code you updated... that's just where it is finally caught and handled... so it must be thrown somewhere in `LargestFirstMemoryManager.getMemoryManagementActions(...)` or something it calls, but it's not clear where that could be from the above description, without a stack trace.
   
   I'm suspicious of Tables.exists returning null (presumably, from line 180 in `LargestFirstMemoryManager`, looking at the 1.10 code), instead of an empty list of children. And, in any case, I don't see how the list can be empty in normal circumstances, because there should always be *some* children there. If there's abnormal circumstances, then I don't think your proposed fix is really going to solve much... because you're just fighting the symptom. If symptoms from ZooKeeper are **that** abnormal, other code is likely going to hit that same broken code path (and you can't handle it the same way everywhere ZooKeeper is used).
   
   I think what we need is a stack trace, in order to try to track down the actual underlying cause, and the specific code that threw the exception.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org