[
https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063904#comment-17063904
]
Erick Erickson commented on SOLR-13492:
---------------------------------------
Sorry to chime in late here, but I'm -1 on this if this will disable, say,
pressing the "gc now" button from jconsole or similar.
When troubleshooting memory issues, there are many times I want to see what
happens to memory after an explicit operation. At times this is in a production
system, and having to restart with different settings here is not necessarily
possible.
Also, this is only one of a million ways people can shoot themselves in the
foot with custom code. This one is in the "might cause performance issues"
rather than the "will cause horrible problems" category.
I'd change to +/- 0 of you can verify that external tools like jconsole _will_
still allow GC to be invoked externally.
> Disallow explicit GC by default during Solr startup
> ---------------------------------------------------
>
> Key: SOLR-13492
> URL: https://issues.apache.org/jira/browse/SOLR-13492
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Solr should use the -XX:+DisableExplicitGC option as part of its default GC
> tuning.
> None of Solr's stock code uses explicit GCs, so that option will have no
> effect on most installs. The effective result of this is that if somebody
> adds custom code to Solr and THAT code does an explicit GC, it won't be
> allowed to function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
