-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
MAPREDUCE-7449: Add add-opens flag to container launch commands on JDK17 nodes #5935
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -170,6 +170,13 @@ public static String expandEnvironment(String var, | |
var = var.replace(ApplicationConstants.CLASS_PATH_SEPARATOR, | ||
File.pathSeparator); | ||
|
||
if (Shell.isJavaVersionAtLeast(17)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just wondering about this. Wouldn't a node-manager config be easer to reason about? Implementing like this is a bit strange, currently MR jobs can be configured (default=true) and the distributed shell app sets this regardless of the configuration. During the job submission/config time it's not clear if container will be launched on a Java>=17 node so that's the reason for the placeholder, later ContainerLaunch replaces it to the arg or an empty string. Maybe non MR apps would also require this option to run properly - which they could specify at the job config - but non-homogenous nodes (where nodes have different Java installs) can't be handled easily (maybe with node labels or some other trick). I think this should be a node-manager config instead. The ContainerLaunch could just simply add the arg when the java version is at least 17 and the config option is set (if we can detect that the container is a java app, not sure about that). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it is not trivial to detect when and where to add this argument, I think the current solution is OK as is. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Had an offline discussion with @tomicooler, the issue with not using a placeholder is the way commands is contructed: in contrast to it's name and type it's a String list containing one element only, the command that is to be executed. In case of Java apps we must add this parameter before the main class, hence I see two options here: add the placeholder right after -Xmx (so that we know it'll be in the correct place) or I can deconstruct the first element of the commands array and add the add-opens flag to the correct place. I think the former is a cleaner, less error-prone solution. |
||
var = var.replace(ApplicationConstants.JVM_ADD_OPENS_VAR, | ||
"--add-opens=java.base/java.lang=ALL-UNNAMED"); | ||
} else { | ||
var = var.replace(ApplicationConstants.JVM_ADD_OPENS_VAR, ""); | ||
} | ||
|
||
// replace parameter expansion marker. e.g. {{VAR}} on Windows is replaced | ||
// as %VAR% and on Linux replaced as "$VAR" | ||
if (Shell.WINDOWS) { | ||
|
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.
avoid space
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.
Fixed, thanks.