-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 226: Pass jvm options #247
Conversation
Signed-off-by: wenqimou <[email protected]>
Does this also make them configurable? I only see hardcoded values. The idea of this fix/PR is to make JVM options configurable from manifest. The operator would still add JVM options it is adding today, but users should be able to override these or add new values they may need. |
Thanks for the review! @andreipaduroiu Yes, it is configurable. There is a method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for the clarification.
Signed-off-by: wenqimou <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #247 +/- ##
==========================================
- Coverage 32.62% 30.96% -1.66%
==========================================
Files 9 9
Lines 1128 1211 +83
==========================================
+ Hits 368 375 +7
- Misses 712 788 +76
Partials 48 48
Continue to review full report at Codecov.
|
@fpj Thanks for the notice. I opened a dup issue before. Fixing the name. |
Signed-off-by: wenqimou <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. It would be nice to have the default JVM values in the example yaml (cr-detailed.yaml
) so people have a template of how to modify these values. Once you address this, I will approve. Note that this PR is a requirement for pravega/pravega#4074, so let's see if we can get it merged soon.
@Tristan1900 it would be nice to merge this PR soon. Could you please address my prior comment regarding adding and "example" of how to modify these JVM values in |
@RaulGracia Oh sure. Doing that now Could you please review it again? Thanks a lot! |
Signed-off-by: wenqimou <[email protected]>
Signed-off-by: wenqimou <[email protected]>
@pbelgundi please, review this PR and merge it asap if there is no additional comments on it. Note that having the functionality of this PR is becoming a pressing issue, as the new streaming cache for Pravega depends on this. |
Looks like some tests are failing? @Tristan1900 would you mind taking a quick look and see if they're related? |
@andreipaduroiu Thanks for the notice! I am debugging it. |
Signed-off-by: wenqimou <[email protected]>
I just found that |
Signed-off-by: wenqimou <[email protected]>
pkg/util/pravegacluster.go
Outdated
return fmt.Sprintf("-XX:%v=%v", k, v) | ||
} | ||
|
||
func OverrideDefaultJVMOptions(defaultOpts []string, overrideOpts []string) []string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this method way too complicated.....
Since the defaultOptions are in code, we could store them in a map instead of a slice like this:
defaultOptsMap := map[string]string {
"-Xms":"512m",
"-XX:+ExitOnOutOfMemoryError":"",
"-XX:+CrashOnOutOfMemoryError",:"",
"-XX:+HeapDumpOnOutOfMemoryError": "",
"-XX:HeapDumpPath=": heapDumpDir,
}
)
For Overriding default values do the following:
- mergedSlice = Create a new slice to holdall options [ overridden defaults + new user provided options + non-overridden default options ]
- for key, value := range defaultOptsMap {
if (key is a prefix for any value in overrideSlice) {
// do nothing, since we want to pick this value from overrideSlice
} else {
// add default value that is not present in overrideSlice
mergedSlice = append(mergedSlice, key+value)
} - return mergedSliced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comment. I see your point and here is what I think,
- If the number of default options is
m
and the number of user-provided options isn
, this lineif (key is a prefix for any value in overrideSlice)
will basically make the time complexity to bem*n
, whereas my current way ism+n
. - Since iteration for map in Go does not follow the insertion order, this line
for key, value := range defaultOptsMap
will make the iteration in random order. However, I found that we have to specifyUnlockExperimentalVMOptions
beforeUseCGroupMemoryLimitForHeap
when passing to the JVM, otherwise JVM will throw an error. So there is an order that needs to be guaranteed when passing those JVM options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to worry about execution complexity here, unless we expect the number of options ( default or user provided) to be > 100. In most cases the number of options provided ( default + user provided) should be not more than 10-15 ( At max this can go upto 30-35) which is too small a number to worry about execution complexity.
It is more important to have clear and readable code that is easier to maintain and reason about.
As regards the order of options, only a few options should be order sensitive and it should be easy to just add them first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some comments to make it more readable. It would be great if you could take a look at it again and see if it works. Thanks!
Signed-off-by: wenqimou <[email protected]>
Signed-off-by: wenqimou <[email protected]>
pkg/util/pravegacluster.go
Outdated
return fmt.Sprintf("-XX:%v=%v", k, v) | ||
} | ||
|
||
func OverrideDefaultJVMOptions(defaultOpts []string, overrideOpts []string) []string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to worry about execution complexity here, unless we expect the number of options ( default or user provided) to be > 100. In most cases the number of options provided ( default + user provided) should be not more than 10-15 ( At max this can go upto 30-35) which is too small a number to worry about execution complexity.
It is more important to have clear and readable code that is easier to maintain and reason about.
As regards the order of options, only a few options should be order sensitive and it should be easy to just add them first.
Signed-off-by: wenqimou <[email protected]>
Signed-off-by: wenqimou [email protected]
Change log description
Pass jvm options to bookie, segmentstore and controller.
Purpose of the change
Fix #226
What the code does
Pass the jvm options, override the default if it exists already.
API change
How to verify it
Unit tests should pass. The manual deployment should also see the options are passed to the jvm.