On 10/7/2016 5:13 PM, Renee Sun wrote: > I just read through the following link Shawn shared in his reply: > https://wiki.apache.org/solr/WhyNoWar > > While the following statement is true: > > " Supporting a single set of binary bits is FAR easier than worrying > about what kind of customized environment the user has chosen for their > deployment. "
One of the historical challenges on this mailing list is that we were rarely aware of what steps the user had taken to install or start Solr, and we had to support pretty much any scenario. Since 5.0, the number of supported ways to deploy and start Solr is greatly reduced, and those ways were written by the project, so we tend to have a better understanding of what is happening when a user starts Solr. We also usually know the relative location of the logfiles and Solr's data. > But it also probably will reduce the flexibility... for example, we tune for > Scalability at tomcat level, such as its thread pool etc. I assume the > standalone Solr (which is still using Jetty underlying) would expose > sufficient configurable 'knobs' that allow me to turn 'Solr' to meet our > data work load. Yes, Jetty's full configuration would be at your disposal. The configuration which tends to matter the most -- maxThreads -- has been pre-tuned to a very large value. The other settings have been set to values that work well for the vast majority of Solr installs. > If we want to minimize the migration work, our existing business logic > component will remain in tomcat, then the fact that we will have co-exist > jetty and tomcat deployed in production system is a bit strange... or is it? > > Even if I could port our webapps to use Jetty, I assume the way solr is > embedding Jetty I would be able to integrate at that level, I probably end > up with 2 Jetty container instances running on same server, correct? It is > still too early for me to be sure how this will impact our system but I am a > little worried. You can take the server/solr-webapp/webapp directory from the download in 5.3 and later, which contains the same information that used to be in the .war file, and install it as a webapp into Tomcat. If you use something other than "/solr" as the context URL, then the admin UI in 6.0 and later won't work right, but Solr itself (the HTTP API) should work just fine no matter what the context URL is. I don't have precise information about how to do this kind of install, but I know it CAN be done. The tomcat documentation refers to this as an "exploded web application" and I think you can deploy such an application either directly by copying it into the correct directory, or with a context file. In the Jetty that comes with Solr, the exploded webapp is deployed with a context file. Unless they use tomcat-specific code, you might also be able to take your other webapps and install them into the Jetty that comes with Solr. The Jetty bits that are included with Solr are identical to a Jetty package downloaded from eclipse.org, with a few components removed that Solr doesn't use. I wrote the "WhyNoWar" wiki page, so any errors that it contains are most likely mine. I'm not aware of any errors, but it's possible that some are there. Thanks, Shawn
