________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 > 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 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 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 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://avatars3.githubusercontent.com/u/414681?s=400&v=4]<https://github.com/eclipse/jetty.project/issues/2711> TLS 1.3 compliance · Issue #2711 · eclipse/jetty.project<https://github.com/eclipse/jetty.project/issues/2711> The TLS 1.3 implementation landed in JDK 11-ea+21. We need to make sure that SslConnection works well with TLS 1.3. In particular: After ClientHello and ServerHello, all other TLS handshake message... github.com - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvBBEsACgkQHPApP6U8 pFgNxw//Xd4IZCtNo0/VHDbYlaaFTAjyWDLvsjWZuDFBZqJq9zBHbE00zMbqjFA0 eQF9/gB8wqctCHZttj124GfoaPP80p4/8SW/myBu239D+UvdWWtF1c61ItOrdkU8 46DlVROxkjsjxmguBL5R7EwJqlYB5feVTRGU7aKkiYxI1A2Jv3+NrejtqtmIxgrW M1TPQfpI7dhyuJ0GqWafmr5oW7hfDt/zrx1f96FiYp2gWnjJXsH7UwfHRWXUvOEa 1b4SlkkpFnrtwjOmX5WiJPSghfHmkPSnshwFe1B4E4MEi3XWQnIqWY5f0ZO8i1ZT /hw1CEBzU/NFnae5ER/uDntzZSMsnVVkmgvQTsyXk41F6VnnpGy1RNc6MOgi4B7X DA96PlXyAbiCaDGTKz6fbPV+5AaaNgfSoJUBTegX/rMbabvHuSLUqjrapzstas03 TTBZNyjIDxICKDXgbNCmPUaJwuxmgpA55b3UWn97E4VmVYyIvohJe3MpZKnLkaf/ 4HRZej0IBBfTywmyIcW0BvC9wWr6PvNN9KpkPrcwUMLN1dHGUV+XZ/ljv4vpoi6m +0nPFtpGQRshrFh3s3BGQo37uCHB+sXTCqwzggb7RU476BtgYBHGB+koMZ+WvnRd u3vwgPmNEhUYroqHHEzeMvRO/3NYrJzehtZ/ubi7YJBF1qXSL5k= =v4NI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
