I don't think that I have ever thought of Solr as an "application". I mean, it is a tool/server that application developers user to develop THEIR application. I've always thought of Solr as a "server", and it has only been incidental (and fairly annoying) that it has been packaged as a "webapp" for deployment in a container.
If anything, I think of Solr as a "server" or "app server" that supports development and deployment of "search apps" - coded primarily in XML. Hardly your typical "webapp". Are there any examples of a tool/server comparable to Solr’s role in “application development” and support for “search apps” that happily live as a mere “webapp”? That said, I'll stay agnostic for now as to the disposition of the war and support for containers such as Tomcat. Keeping war support in 4.x and dumping it in 5.0 seems fine, but... Meanwhile, I'd like to see the Solr "example" grow up into a "production/deployment example." -- Jack Krupansky From: Walter Underwood Sent: Saturday, May 04, 2013 6:35 PM To: [email protected] Subject: Re: VOTE: solr no longer webapp Let's not reject the classic replication mode out of hand. The tight coupling in Solr Cloud brings along a host of failure modes. For systems that do not have tight freshness requirements, regular old replication is awesome. The loose coupling allows extremely simple failure recovery. For example, AWS region failover is trivial with good ol' Solr replication. With Solr Cloud, I cannot figure out a way to do it. That happens to be a requirement from ops. Also, comparing this to MySQL and Postgres is silly. There is no web framework for C or C++. Instead, let's name a few major Java applications that do not use servlet containers. wunder On May 4, 2013, at 2:25 PM, Mark Miller wrote: Supporting both just compounds our problems and doesn't go very far towards solving any. The only place the webapp will end up still making sense after a bit of time is in non solrcloud mode. The improvements it will bring will make it a dumb choice if you use SolrCloud. We already have enough baggage holding up SolrCloud because of supporting the std mode - adding to the list only makes my life even harder. We need to reduce the number of configurations we ship, not multiply them. I believe *very* strongly. We must start to focus the beam, there is already to much diffraction. - Mark On May 4, 2013, at 2:09 PM, Grant Ingersoll <[email protected]> wrote: Why not just support both? It really isn't all that hard. While I agree w/ Robert and Mark that it's time to consider alternatives, I also don't think it is all that hard to support both from a user's perspective. We could have a Netty(or other) version and a WAR version and I don't think it is that big of a deal to maintain. After all, we already have the component pieces as JARs, just bundle them up differently for Netty, etc. -Grant On May 3, 2013, at 8:09 PM, Otis Gospodnetic wrote: But I'm really curious, what is the problem with Solr inside a container? Which problem is this solving? I feel like I missed some important thread.... which is highly possible. :) Thanks, Otis On Fri, May 3, 2013 at 1:14 PM, Robert Muir <[email protected]> wrote: # rm -rf tomcat # gzip -dc solr.tgz | tar -xvf - # cd solr/example # java -jar start.jar On Fri, May 3, 2013 at 9:52 AM, Steve Molloy <[email protected]> wrote: So, if ever this passes, what would be the upgrade path for all the deployments using Solr as a webapp inside tomcat or other container? ________________________________________ From: Michael McCandless [[email protected]] Sent: May 3, 2013 12:09 PM To: Lucene/Solr dev Subject: Re: VOTE: solr no longer webapp On Fri, May 3, 2013 at 12:14 AM, Robert Muir <[email protected]> wrote: I think solr should no longer be a war file but a search app. I don't care how it accomplishes this: jetty, netty, its all up to us. Let me know your ideas: I think its a necessary step to move solr forwards. +1 Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -------------------------------------------- Grant Ingersoll | @gsingers http://www.lucidworks.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -- Walter Underwood [email protected]
