Can we stick to the question? Which is "what advantages Tomcat might bring to be worth the _very_ significant effort it would take to replace Jetty, assuming that it's a choice between the two".
For the level of effort required to make the switch to Tomcat, I suspect the consensus would be to use neither and switch to Netty or similar, which makes the discussion so far pretty much a waste of electrons. Erick Erick On Sat, Oct 13, 2018 at 6:24 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Martin, > > Wow, wild conjecture with no supporting evidence. Seems like par for > the course with you. Read on, if you dare. > > On 10/13/18 13:41, Martin Gainty wrote: > > > > ---------------------------------------------------------------------- > - -- > > > > > *From:* Christopher Schultz <ch...@christopherschultz.net> > > *Sent:* Friday, October 12, 2018 4:30 PM *To:* > > dev@lucene.apache.org *Subject:* Re: Academic question about Solr's > > embedded web server > > > > Shawn, > > > > On 10/12/18 15:52, Shawn Heisey wrote: > >> On 10/12/2018 1:18 PM, Christopher Schultz wrote: > >>> I'm curious as to why Solr uses Jetty and not Tomcat. > > > >> I wasn't part of the project when that decision was made. Jetty > >> was already included with Solr when I first downloaded it -- > >> Solr version 1.4.0, back in 2009. Jetty wasn't quite as > >> integrated as it is now, and at that time, Solr was still > >> shipping as a WAR, suitable for any container. > > > >> I'm going to offer my two cents, which I admit up front is only > >> an educated guess. Others can probably give you concrete > >> information about discussions that happened nearly a decade ago. > > > >> I think the primary reason is that Jetty is more lightweight than > >> Tomcat. > > > > I think this is more of a perception than actual truth. MG>dead > > wrong > > Dead, eh? Tomcat performs on-par with Apache httpd. Where is the > "heavy" in those numbers? > > >> And the Jetty that's included with Solr is considerably stripped > >> down compared to a standard binary distribution, so its > >> footprint is VERY small. Since Solr 4.0 when Solr's UI > >> completely changed to Javascript, even JSP support is missing. > > > > When you consider "footprint", do you mean on-disk or in-memory? I > > ask because Tomcat can be used in an embedded mode where you > > basically only enable things that you want. For example, if you > > don't want JSP, you simply don't bring-up the JSP engine on > > startup. If Solr doesn't use Websocket, then you don't have to > > enable that, either. Tearing-out the various JAR files might be > > more tricky and it may be simpler to leave the unused classes > > sitting around, unused. MG>inefficient > > In what was, specifically? Memory usage? CPU usage? Under what load? > Which connector? Which JVM? I have ready answers for all of these > questions. Are you just taking pot-shots or do you have real-world > evidence. Because I do, and many others do as well. > > > It might be safe to drop a few of the stock JAR files to save some > > disk space, but it would be best if you/we didn't have to crack > > anything open and remove anything from existing artifacts. If there > > is a use-case for further-decomposing Tomcat into more JAR files so > > that more of them can be removed for e.g. Solr (and anyone else > > using Tomcat-embedded), then that is worth considering. > > > >>> We'd like to make Tomcat such that, if you had the choice to > >>> make again, you might pick Tomcat instead. > > > >> If you can make a very compelling argument about benefits we > >> would see from moving to Tomcat, and can help us modify things > >> like our testing infrastructure and scripting to make it all > >> work, I see no reason we wouldn't give it serious consideration. > >> It would be VERY important for the test infrastructure to use the > >> same container as the binary distribution. That's probably the > >> biggest source of inertia that keeps us where we are. > > > >> Take a look at SOLR-6733 (and its child SOLR-6734) in Jira for > >> some ideas I've been tossing around for embedding the container > >> directly into Solr itself, so that Solr is a standalone > >> application. I never have the time I need to work on it, and it's > >> a really major task. I know from work I've done using Spring > >> Boot that Tomcat can also be embedded. > > > > MG>as you are using the embedded model from Spring > > Uh, what? Spring boot is still wet behind the ears, son. Tomcat has > has an embedded mode since long ago. ~10 lines of code gets you going. > > > I didn't realize that Solr wasn't using Jetty embedded. I just > > assumed that it was. If you are thinking about turning Jetty > > inside-out so that you launch Solr and Solr launches Jetty, then > > actually now might be a good time to re-consider using Tomcat > > versus Jetty. MG>that would only be true if your support didnt > > spend all their time on self-serving evasive answers MG>look at the > > 100s of JIRA requests that were torpedoed by MarkTrump > > Hmm. I'm not sure why I even bothered responding. Maybe it's because I > have technical arguments about things instead of resorting to ad > homonym attacks. > > > Self-hosting a Tomcat instance (i.e. embedded usage) is fairly > > straightforward: create an instance of the Tomcat class and add > > connectors (port binding), web applications, etc. Presumably, > > you'd add one or maybe two connectors (HTTP and/or HTTPS) and then > > a single web application: Solr. > > > > MG>TC drags their feet on SSL conformance MG>no matter.. TLS v1.3 > > is the new standard and I guarantee you MG>TC will never catch up > > to that standard MG>implement jetty 9.4.12 > > https://github.com/eclipse/jetty.project/issues/2711 > > <https://github.com/eclipse/jetty.project/issues/2711> > > Uhh... all supported releases of Tomcat will have TLSv1.3 support in > the next point release: 9.0.13, 8.5.35, and 7.0.92. Both in > NIO+OpenSSL mode (native = much faster) or NIO/BIO + JSSE mode (for > JVMs which support it). Works with CLIENT-AUTH as well. Tomcat is on > track to beat the mainstream web browsers to market with TLSv1.3 support > . > > Feel free to tilt at whatever windmills you wish, Martin. The rest of > us will calmly continue and ignore the noise with which you fill the air > . > > I appreciate the opinions of the rest of the Solr community on this issu > e. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvCmsgACgkQHPApP6U8 > pFingg//SmbdPqHgvfxE+y7y0uKdkou60zIZE9juwfTJIjm76wOd7GQE+eSPhCO9 > 6WCO9HSyeK1I20NhwH9qP9L8ZQl5fDqeBAQt2IpUsszB0NsmMEXW3ylapqt1Ob2i > 39LdLRJRgNoiPUsZU75BHBcNA2XBpeRa/BryEWmIzkAkIfRuypqyCQb/B7ThbNFO > Gaqi3jBbi/ESAy0V1h8ekczMMl+KzswGgezgnE1pNEDZDB5CuIZDnhAE9OImLzmY > zcSGfthaYMwgZNA7ZsBEL34UZ4ZTxPNl9TZ1ibH36AoHtxTmxtrSV/1fU9vFeWlD > Y8DBjQj682xv2vQdxEJP8bmkAGzE+NvlA6p1fIfxSM4cw00zwQO6JOReVSzEwHUv > BuJhlhvHge9uQqTGU6qAZtTqIAmqYqgyOucHBnOY0HgFK8zpz4PacQkFcl4nKZdu > pxOP0E47SkMKqvVStmJzVHwMZY+UIG8aSqdoveLk0dRxILXoyijsXjbTnViGjP+O > NhNzohKNpE1NHGamZFBzszal6nVK8pOlMpPm4veJzEVvP5OsEAv1DOxYsJN9XouE > mOrq9d4krjqvoWzhTdohU72bZpU1ldWvypCf6cxzkUSC0wLBsx9rGj6QgzMG/BOv > k3C3OAGGXv1gaU51LMnBfQcGwX1ZeiQSB5YZxRDaKHDoQeT3S80= > =7tP/ > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
