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]
