[
https://issues.apache.org/jira/browse/CASSANDRA-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201024#comment-13201024
]
Peter Schuller commented on CASSANDRA-3675:
-------------------------------------------
I don't understand. If you have fragmentation problems, you're going to take
full gc:s that do compaction anyway when you have a promotion failure so it's
not like you're not going to get your heap compacted.
Are you saying people are expected to be in the category of people that want to
pre-emptively run full compacting GC:s, yet want to do so ad-hoc without
changing GC settings and scripting around it?
> ship with -XX:+ExplicitGCInvokesConcurrent by default
> -----------------------------------------------------
>
> Key: CASSANDRA-3675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3675
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Peter Schuller
> Assignee: Peter Schuller
> Priority: Minor
> Fix For: 1.1
>
> Attachments: CASSANDRA-3675-trunk.txt
>
>
> It's so much easier if you can safely tell people to trigger a full GC to
> discover their live set (see CASSANDRA-3574), instead of explaining the
> behavior of CMS and what the memory usage graph looks like etc etc. Shipping
> with {{-XX:+ExplicitGCInvokesConcurrent}} means this is by default safe.
> For people that have special needs like some kind of rolling compacting GC
> with disablegossip, they are special enough that they can just change the VM
> options.
--
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
