ctubbsii commented on issue #4076: URL: https://github.com/apache/accumulo/issues/4076#issuecomment-1856858471
I think that a shutdown request handler and exposing sufficient metrics for an external decision-maker to request a shutdown would probably be better than baking in properties and logic to handle them. It would put less burden on Accumulo to reimplement complex scenarios that might be valid use cases. Just keeping it simple by being able to handle a shutdown request and letting the decision happen outside of Accumulo can keep Accumulo's complexity low without limiting the supported use cases. For instance, Amazon EC2 can scale dynamically through external mechanisms and although I'm not really an expert on these systems, I believe it to be possible emit metrics from your VMs to drive the decision. From what I understand, the VMs just receive an ACPI power off signal, and the OS can shut down gracefully, including triggering any systemd services to shut down gracefully. That could easily be done for Accumulo services with a good systemd unit file, whether it involved a graceful shutdown, or just killing the process. I also had a discussion with a researcher awhile back who had some expertise in designing robust systems. Their argument was that if your system is robust enough, it's not worth even baking in any kind of graceful shutdown handling... just killing the process would be sufficient because graceful shutdowns are just redundant code paths where more consistency-related errors can occur. I think he had a good point, but I don't think I could communicate his arguments as well as he could, and I can't remember his name. So, I take it as just something to consider. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
