On 10/15/2018 2:15 AM, Jäkel, Guido wrote:
I have no experience with embedded tomcat, but it should be also straight
forward. Said that, I can't imagine the advantage of such an approach against
the currently used, which just start the Web Application Server (Jetty, Tomcat
or whatever) with the preinstalled Solr application.
Probably the top reason for embedding the network layer (currently
Jetty) is to have all of the global config (both for the
network/container layer and for the Solr node itself) live in one place.
Right now, when running in cloud mode, a node could register itself with
the cluster using completely invalid information -- wrong host/address,
wrong port, wrong context path (normally /solr -- changing it causes big
problems with 5.0 and later). Changing to embedded would allow us to
ensure that the info used in node registration is the same info used to
initialize the node. It would be overall much cleaner, and we would be
able to finally say that the end user is starting Solr -- not Jetty or
any other container.
Here's the info about why things are as they are currently, with a
little bit of info about where we want things to end up:
https://wiki.apache.org/solr/WhyNoWar
Christopher already shared the issue I filed for the effort in setting
Solr up as a standalone application. It is an umbrella issue with one
child issue currently:
https://issues.apache.org/jira/browse/SOLR-6733
Another point in Jetty's favor: We are in the process of switching from
Apache httpclient to Jetty httpclient, for http/2 support. The new
Apache client with http/2 support is only recently into beta status. It
was in alpha state for a REALLY long time, and we expect the beta state
to last for another several months, possibly a year or longer. The
jetty client with http/2 support has been available in a stable version
almost as long as the http/2 RFC has been published, and has had all
that time with heavy usage for the showstopper bugs to be worked out. I
personally think it's tragic that we're switching away from Apache for
our httpclient, but I'm in favor of the switch for the reasons
outlined. Compatibility with the server is expected to be better if
both are from the same development team.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
