lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3613) Namespace Solr's JAVA OPTIONS
Date Wed, 11 Jul 2012 19:38:34 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411890#comment-13411890
] 

Mark Miller commented on SOLR-3613:
-----------------------------------

bq. What do we gain in restricting deployment options, as long as it's simple enough to keep
Solr a clean web-app?

We can do more around out of the box goodness like process management and good logging and
have tools and things that know where to find those. Like a good normal application. It also
lets us stop worrying about how we behave 'as webapp' and put that energy elsewhere. It also
would let us not worry about testing and supporting all these other containers. They could
simply be second class best effort, and our primary effort gets better. That is basically
matching thinking with reality - as it is, all of our unit tests run in jetty. Most of the
use of Solr is in Jetty. Most of the bugs we find at the container level are around Jetty.
We have had to patch the version of Jetty we are using to avoid bugs, upgrade Jetty to avoid
bugs. If you are not using our shipped Jetty, your probably not doing it right if you ask
me.

bq. This is one of the risks of running TRUNK or ALPHA before a FINAL release. 

That is not really how I look at it. 4 was a special case that took place over years - I care
more about the practical effect of the change than I do some rule about when I should easily
screw existing users. Using releases promises you back compat to some degree - not using them
doesn't mean we will change things wily nilly on you if we can help it. You have to weigh
the gains, which seem minimal at best here IMO.

I'm flexible on what we do for this issue overall, but I've stopped thinking about Solr as
a webapp - like I said, I don't see the gains, and I've seen how that thought process has
held back a good out of the box experience.
                
> Namespace Solr's JAVA OPTIONS
> -----------------------------
>
>                 Key: SOLR-3613
>                 URL: https://issues.apache.org/jira/browse/SOLR-3613
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 4.0-ALPHA
>            Reporter: Jan H√łydahl
>             Fix For: 4.0
>
>
> Solr being a web-app, should play nicely in a setting where users deploy it on a shared
appServer.
> To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid name clashes
and for clarity when reading your appserver startup script. We currently do that with most:
{{solr.solr.home, solr.data.dir, solr.abortOnConfigurationError, solr.directoryFactory, solr.clustering.enabled,
solr.velocity.enabled etc}}, but for some opts we fail to do so.
> Before release of 4.0 we should make sure to clean this up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

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


Mime
View raw message