Status

Current state: Under Discussion

Discussion thread: https://lists.apache.org/thread.html/r044e037c70272965a088dfee9c027f8f268fbb27406737fda24854e1%40%3Cdev.lucene.apache.org%3E

JIRA: SOLR-14361

Released: No

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.

Motivation

Currently we bootstrap Solr with java -jar start.jar, which is Jetty's default bootstrap code. Then Jetty does its thing, loads the Solr servlet and then CoreContainer starts its initialization. Way back before 5.x Solr was shipped as a WAR file to be deployed in any servlet container. Then from 5.x we did not support that anymore but still start Jetty as if it was a generic servlet container, loading Solr's servlet from web.xml etc.

This ties our hands a bit as we cannot freely decide on startup parameters such as (-Djetty.port), we don't gain early access to the JVM process to e.g. lock memory, and we cannot easily take programmatic control over things configured in web.xml or other jetty configs like jetty-ssl.xml.

Writing our own bootstrapper enables us to do all this and finally let Solr be a true standalone app, which happens to start Jetty as its HTTP layer.

Public Interfaces

There will be a new solr.jar along with potentially changed/added startup parameters for how to start Solr. We may be able to simplify/unify how we configure the webserver part of Solr, without touching jetty specific xml files.

Proposed Changes

The most important change in this SIP will be

• Create a solr/bootstrap module with a solr.jar  to replace start.jar  as the entrypoint (java -jar solr.jar ...)
• Write our own bootstrap code which will load Solr's webapp using WebappContext loading the existing web.xml. This will replace Jetty's Main class scanning for servlet contexts.
• Hide jetty even more, i.e. rename jetty.port  → port , and perhaps clean up other Sysprops as well
• Be able to lock Solr's memory to prevent swapping (SOLR-14335)

This will then in turn enable many many other improvements which are currently not in scope for this SIP but may be followup JIRAs, such as:

• Get rid of web.xml entirely by defining a SolrServletContextFactory interface pluggable in solr.xml, which will default to setting up the servlet in Java code. People with need to customize web.xml can then provide their own custom implementation of the factory, which will do what they need.
• Be able to shutdown JVM in various error situations (SOLR-6935 etc)
• Easier to control things like CORS in our own config (SOLR-12292)
• Get rid of jetty-ssl.xml and instead control SSL config in Java code, driven by Solr config
• Slim down bin/solr & bin\solr.cmd and move more startup logic into our bootstrap Java code
• Unified handling of key timeout values (SOLR-13457)

Compatibility, Deprecation, and Migration Plan

This will not be very visible to customers, we can maintain bin/solr syntax.

People who monitor Solr or have scripts checking for start.jar in the command line or manually injecting -Dxxx=yyy arguments or who edit web.xml or jetty xmls manually may need to adapt depending on what we change there.

Security considerations

TBD

Test Plan

There should be new tests that start Solr app in the new way.

If we move servlet initialization into Java code and get rid of web.xml, we may be able to start Solr in the same way both in tests and in real life!

Rejected Alternatives

Continue as today

There are clear benefits with the new model

Move to Netty

Even if we move to Netty, we will need our own bootstrapper to start netty from, so this would be the first step anyway