[
https://issues.apache.org/jira/browse/CASSANDRA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schuller updated CASSANDRA-2023:
--------------------------------------
Attachment: 2023-v2.txt
v2 is significantly simpler and cleaner (IMO). Tested on MacOS and Linux.
FWIW, the reason I didn't do "must set both" initially is that I felt the new
size was a lot more obscure/advanced than merely setting heap size. v2 tries to
mitigate this by documenting what to do if unsure/don't care.
> 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
> Reporter: Peter Schuller
> Assignee: Peter Schuller
> 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.
