-----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 <[email protected]> > *Sent:* Friday, October 12, 2018 4:30 PM *To:* > [email protected] *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: [email protected] For additional commands, e-mail: [email protected]
