On 5/4/2013 2:42 PM, Mark Miller wrote: > * super simple improvements, like not having to name space sys props to solr. > * releasing an app that is tested and works - already things have come up > where something works in jetty and not tomcat and many users struggle with > all kinds of problems trying to shove solr into weblogic or other containers. > lets get all our users on one set of bits that we ship, not some wonderland > of combinations that we don't control - there are real benefits to this! > * Deal with SLF4j in a nice way that doesn't cause Robert to claim we broke > the war. > * what if Solr was actually two processes and not one? what if there was an > agent that could start and stop solr? stop and start your cluster with a > single command? update your cluster automatically by kicking off a command? > The agent could restart Solr? What if things like heap size could live in ZK > and out of the box you just had to configure that stuff in one spot? > Shouldn't you be able to configure all of Solr rather than rely on users cmd > line arguments? > * webapps cannot tell what port they are running on except within a > request…yuck. > * shouldn't we be able to use specific features and improvements that not all > containers support? Shouldn't we be able to plug and play the underlying http > layer technology? > * shouldn't we be able to try and use embedded jetty and its nice integration > with guice+restlet? Check out using netty? > * why should we ship advertising a format that begs running other apps in the > same Solr process! This is a terrible idea for a search engine.
Those are awesome reasons to switch. I thought there might be some, and now I've seen enough of them to change my vote: +1 If a .war build option is still available for a while, then I think we'd be covered. I really like the idea of Solr being two processes, as long as it is clean and cross-platform. Does Java support starting another instance of the JVM in a "direct" manner, or would it be a case of calling the executable with commandline options? Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
