[ODLPARENT-1] allow adding non -X JVM args Created: 02/Apr/14  Updated: 06/Sep/21  Resolved: 06/Sep/21

Status: Verified
Project: odlparent
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: David Goldberg Assignee: Vratko Polak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issue Links:
Blocks
blocks MDSAL-55 Topic: Continuos: Decrease technical ... Resolved

 Description   

we want to be able to add JVM args to the controller like gc:verbose, but currently we can only add -X args



 Comments   
Comment by Devin Avery [ 08/Apr/14 ]

We do support -D options as well. Though it seems the "help" (usage) message for run.sh lies. it states that all extra parameters will be passed to the JVM, but in reality if it is a matching argument, and doesn't start with -D or -X then it fails the run.

Sounds like we should just make the run.sh/run.bat do what the usage says - any non-special opts get passed to the JVM directly instead of failing to run.

Comment by Devin Avery [ 10/Apr/14 ]

CONTROLLER-303 was created to add more OOB parameters to the scripts. Consider doing these defects at the same time.

Comment by Tony Tkacik [ 11/Nov/14 ]

This needs to be revisited for Karaf based distribution if we still have problem with it.

Comment by Tony Tkacik [ 13/Nov/14 ]

Added as blocking issue for Topic: Decrease Technical Debt.

Comment by Vratko Polak [ 15/Dec/14 ]

Is this really a bug for "controller" project (as opposed to "integration project)?

The Karaf way of changing JVM parameters seem to be Service Wrapper.
karaf.apache.org/manual/latest/users-guide/wrapper.html

We should pick one way of setting JVM parameters, document it in Developer Guide (or somewhere else) and deprecate workarounds as those described in INTEGRAT-20.

And finally, current Karaf defaults seem to be a little low for current ODL needs, so it would be good idea to add something to ODL build process that would override or edit various Karaf files.

Comment by Vratko Polak [ 16/Dec/14 ]

> Is this really a bug for "controller" project (as opposed to "integration
> project)?

Oh, now I see that for some reason, Karaf resources are located in "distribution" subdirectory in controller repository. So until they are moved to integration, this remains to be a controller bug.

Back to JVM args. Quick patch for stable/helium branch: https://git.opendaylight.org/gerrit/#/c/13685/

Not sure if such patch suffices for Lithium.

Comment by Carol Sanders [ 04/May/15 ]

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL

Comment by Devin Avery [ 04/May/15 ]

Moving to karaf as it is really about modifying the karaf start scripts to allow other arguments be passed to JVM, and not anything specifically tied to ADSAL.

Comment by Ryan Goulding [ 17/Nov/15 ]

Check with karaf to see if karaf passes environment variables to JVM.

Comment by Vratko Polak [ 18/Nov/15 ]

> if karaf passes environment variables to JVM

It does pass some of them, mainly JAVA_OPTS.
But I believe this Bug refers to command-line arguments. Currently all arguments to bin/karaf are understood as arguments to Karaf (as opposed to JVM). Even the -X* arguments do not work now.
On the other hand, there is bin/setenv as another place users can edit in their options.

I believe most user are now familiar with Karaf ways, so this may be set to WONTFIX. Especially considering that Version is specified to be Helium.

Comment by Ryan Goulding [ 18/Nov/15 ]

Agreed; setting to "RESOLVED", "WONTFIX".

Comment by Vratko Polak [ 19/Oct/16 ]

Resurrecting this as a contribution is available: https://git.opendaylight.org/gerrit/47062

Comment by Vratko Polak [ 06/Nov/17 ]

Since Nitrogen, realized by patching the karaf script, for example see [1].

[1] https://github.com/opendaylight/odlparent/blob/release/nitrogen/karaf/opendaylight-karaf-resources/src/main/patches/karaf-karaf-4.0.9.patch#L67-L70

Generated at Wed Feb 07 20:27:21 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.