You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by GitBox <gi...@apache.org> on 2021/11/01 17:54:45 UTC

[GitHub] [accumulo] ctubbsii commented on issue #2331: OutOfMemoryError During BinMutations cause stuck BatchWriter

ctubbsii commented on issue #2331:
URL: https://github.com/apache/accumulo/issues/2331#issuecomment-956451489


   Trying to recover from Errors seems like the moldy bread of the Java world. Yeah, sure, *maybe* you can cut around the problem, and continue eating safely, but it's not a great idea. When mold occurs, you can't trust that there's not mold in smaller, less visible amounts on the rest of the loaf. Similarly, when an Error occurs, I don't see how you can trust the rest of the state of the JVM... especially something like OutOfMemoryError, which can have cascading effects on other threads in the JVM, possibly really important ones in your dependent libraries or even internal to Java itself. Errors aren't just something you can catch, clean up, and have confidence that all is fine afterwards... they reflect a serious problem with the overall state of the application. Java's own documentation says that these are likely not recoverable, so I have a hard time understanding the desire to try to recover from them, or the confidence that one will actually be able to pull it off reliably with
 out unforeseen consequences.
   
   Even if we were to make OutOfMemoryError in these particular threads not terminal, we can't assume Errors in the general case are safe enough to try to handle. So, we'd have to start baking in heuristics to try to determine which of the "likely not recoverable" errors we believe are more likely than others to be able to recover from, and we have to include assumptions about what triggered the Error as part of those heuristics. Or, we have to treat them all the same, and pass these through to calling client code, to let them decide what to do. Either way, that seems likely to increase code complexity, to support highly questionable behavior.
   
   If there's a high demand or strong use case for it, I suppose I could support the idea of making the uncaught exception handler pluggable via client API. But, it really seems like a bad idea to me... just like moldy bread.


-- 
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.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

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