[
https://issues.apache.org/jira/browse/CASSANDRA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2023:
--------------------------------------
Reviewer: urandom
Component/s: Packaging
Affects Version/s: 0.7.1
Fix Version/s: (was: 0.7.2)
0.7.1
> fix regression in 1968 (young gen sizing logic)
> -----------------------------------------------
>
> Key: CASSANDRA-2023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2023
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
> Affects Versions: 0.7.1
> Reporter: Peter Schuller
> Assignee: Peter Schuller
> Fix For: 0.7.1
>
> Attachments: 2023-v2.txt, 2023.txt
>
>
> 1968 introduced a regression (there was still cleanup to do). In particular
> it broke when an explicit MAX_HEAP_SIZE was set. Attaching *draft* patch
> (needs more testing).
> Allowing automatic newsize calculation in the face of a manually specified
> MAX_HEAP_SIZE was problematic. Either one has to duplicate JVM parsing of
> MAX_HEAP_SIZE or ask the user to set MAX_HEAP_SIZE_IN_MB (or similar) instead.
> In this patch (consider it a draft) i opted for the latter + picking up
> MAX_HEAP_SIZE for backwards compatibility (but with the effect that it
> disables new size calculation). I tried to make it slightly more posixly
> correct, but as usual no guarantees given that I have no posix shell to test
> it on.
> I'm not really happy about the shell acrobatics and my confidence that there
> is not some left-over issue is not high. Should we just not worry about
> MAX_HEAP_SIZE compatibility and remove all that compatibility cruft? Plenty
> of acrobatics left still, but it would remove the more hideous parts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
