lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: VOTE: solr no longer webapp
Date Sat, 04 May 2013 20:42:48 GMT

On May 4, 2013, at 11:59 AM, Robert Muir <rcmuir@gmail.com> wrote:

> 
> 
> On Fri, May 3, 2013 at 8:09 PM, Otis Gospodnetic <otis.gospodnetic@gmail.com> 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. :)
> 
> From my perspective the problem it would solve is giving more flexibility to make solr
easier to use. I know for example Mark wants to make it easier to setup and use solr cloud
but if we tie his hands by requiring that solr still look like a 15-year old application,
then thats exactly what it will continue to be.

Right, it's not even about solving a specific problem…I guess if I was to spitball since
I'm just sitting around and recuperating today anyway:

* 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.

That's my 2 minute dump, but honestly, I think of 5 new reasons every month this webapp situation
is just a limitation - it prevents cool stuff and provides very, very little benefit. People
see the webapp and think, man, a webapp, we have to use the company std webapp container!
Usually this is not a great idea. Search engines are sensitive to these things. See tomcats
not defaulting to utf-8, see the custom version of jetty we had to release once. By not using
what we ship, users are rolling the dice, and we are promoting it. Silly stuff.

Solr should own this layer. As Uwe once said:

Do you install MySQL inside a servlet container? Do you install PostgreSQL inside a servlet
Container? NO!

- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message