cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2023) fix regression in 1968 (young gen sizing logic)
Date Mon, 24 Jan 2011 20:00:52 GMT


Hudson commented on CASSANDRA-2023:

Integrated in Cassandra-0.7 #199 (See [])
    fix young gen sizing logic

Patch by Peter Shuller (w/ minor changes); review by eevans for CASSANDRA-2023

> fix regression in 1968 (young gen sizing logic)
> -----------------------------------------------
>                 Key: CASSANDRA-2023
>                 URL:
>             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.

View raw message