Such a big change in behavior is best done in major release. It’s not a bit problem for systems like k8s that use liveness probes. But for normal installs and for plain Docker installs it would be a benefit if the jvm process simply exits on fatal error, so the daemon process need not be as advanced.
Do we need to own the bootstrap (replace start.jar) in order to do this, or is it possible to configure jetty in such a way? Jan Høydahl > 24. jan. 2022 kl. 21:10 skrev Mike Drob <[email protected]>: > > > Is this a 9.0 blocker? Seems like any APIs we change would be internal only? > >> On Mon, Jan 24, 2022 at 9:26 AM Jan Høydahl <[email protected]> wrote: >> Hi, >> >> Solr runs in a servlet container (Jetty), and normally you want one webapp >> to not be able to cause issues for another one by e.g. running System.exit(). >> But Solr is different, it is the only servlet in the container, and in >> certain cases (such as syntax error in config files during startup), there >> are exceptions in the logs (such as ClassNotFound), Solr's servlet was never >> initialized, so returns a cryptic HTML page, while Jetty remains running. >> >> Is there a way we could allow some classes responsible for bringing up Solr >> to call Jetty's life-cycle command to shut down the entire Jetty JVM? >> I don't think we should allow all plugins, 3rd party tools etc to do this, >> but our own bootstrapping and config parsing code. >> >> Jan >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >>
