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

Shawn Heisey commented on SOLR-7850:
------------------------------------

If the user doesn't replace their solr.in.sh script, then they probably won't 
have an issue on upgrade ... but then they might be missing out on a bugfix or 
a performance-enhancing update.

Now that I get a good look at solr.in.sh, the only things it does out of the 
box are set the max heap and the GC tuning options.  All the other things in 
there are commented ... so now it makes a lot more sense as to why it would be 
set up the way it is.  I think those default options should be in the main solr 
script, and it should be possible to override them in an additional script, 
with a sample version of that additional script provided in the download.

> Move user customization out of solr.in.* scripts
> ------------------------------------------------
>
>                 Key: SOLR-7850
>                 URL: https://issues.apache.org/jira/browse/SOLR-7850
>             Project: Solr
>          Issue Type: Improvement
>          Components: scripts and tools
>    Affects Versions: 5.2.1
>            Reporter: Shawn Heisey
>            Priority: Minor
>
> I've seen a fair number of users customizing solr.in.* scripts to make 
> changes to their Solr installs.  I think the documentation suggests this, 
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts 
> which such a user would want in their setup, but if they replace the script 
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user 
> customization script, in a similar manner to linux init scripts that look for 
> /etc/default/packagename, but are able to function without it.  I'm not 
> entirely sure where the script should live or what it should be called.  One 
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of 
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java 
> app as detailed in SOLR-7043, then the same thing should apply there -- have 
> a config file for a user to specify settings, but work perfectly if that 
> config file is absent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to