Reporting Java system properties default values

In many cases we might want to check what are the default value for a certain Java property.
This helps in tuning Java applications and also in predicting application behavior when based on those default values.

Java sets many properties by default unless you chose to provide other values.
To report all Java properties for a given JVM we use the below form:

java -XX:+PrintFlagsFinal -version

This will list all the applicable properties to that JVM.
To find a certain property on Windows, we can use the findstr command which works like grep:

C:\Users\sherif>java -XX:+PrintFlagsFinal -version|findstr /I heapsize
    uintx ErgoHeapSizeLimit                         = 0
          {product}
    uintx HeapSizePerGCThread                       = 87241520
          {product}
    uintx InitialHeapSize                          := 100663296
          {product}
    uintx LargePageHeapSizeThreshold                = 134217728
          {product}
    uintx MaxHeapSize                              := 1591738368
          {product}
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

C:\Users\sherif>

This shows that the default max heap size is set to be 1.5GB by default for the 64-bit JVM if we didn't specify a heap size.

Another useful option for Java is the showSettings:properties option, this will show system related settings like the OS type, CPU architecture, and boot class path.
The form looks like this:

java -XshowSettings:properties -version

The output is printed on Windows standard error thus normal piping wouldn't work with it.

Rundeck Parametric Job Definition

I have a use case where I need to run same set of shell instructions multiple times with different users and compare the results on remote hosts.

Thought about automating this using Rundeck, and since I am not allowed to use ssh keys password-less authentication in this case, Rundeck would be ideal.

below is a sample job listing (XML) for a parametric job that accepts username and a password and just prints the username in a simple embedded shell script.

<joblist>
  <job>
    <context>
      <options preserveOrder='true'>
        <option name='Password' required='true' secure='true' valueExposed='true' />
        <option name='User_Name' required='true' value='App_User' />
      </options>
    </context>
    <description></description>
    <executionEnabled>true</executionEnabled>
    <id>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</id>
    <loglevel>INFO</loglevel>
    <name>Parametrized_job1</name>
    <scheduleEnabled>true</scheduleEnabled>
    <sequence keepgoing='false' strategy='node-first'>
      <command>
        <script><![CDATA[echo "This is a test Job"
echo 'using form $RD_OPTION_USER_NAME' $RD_OPTION_USER_NAME
echo 'using form ${option.User_name}' ${option.User_Name} #doesn't work :)
echo 'using form \@option.User_name\@' @option.User_Name@
]]></script>
        <scriptargs />
      </command>
    </sequence>
    <uuid>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</uuid>
  </job>
</joblist>

The job parameters are better accessed as passed by Rundeck env. as:$RD_OPTION_paramname

The above job option env. variable will be passed to all rundeck executed scripts so it is much easier to use it in this form than the one between @ signs.
The form ${option.User_Name} is not working in this case as Rundeck will use it as a command-line argument if we are running a commad step rather than an embedded script.

below is an example job definition:

<joblist>
  <job>
    <context>
      <options preserveOrder='true'>
        <option name='Password' required='true' secure='true' valueExposed='true' />
        <option name='User_Name' required='true' value='App_User' />
      </options>
    </context>
    <description></description>
    <executionEnabled>true</executionEnabled>
    <id>5d1db9a0-d381-49ec-8981-c483b375751c</id>
    <loglevel>INFO</loglevel>
    <name>Parametrized_job2</name>
    <scheduleEnabled>true</scheduleEnabled>
    <sequence keepgoing='false' strategy='node-first'>
      <command>
        <exec>echo ${option.User_Name}</exec>
      </command>
    </sequence>
    <uuid>5d1db9a0-d381-49ec-8981-c483b375751c</uuid>
  </job>
</joblist>

Rundeck parametric jobs will prove very useful for doing generic tasks and generic automation.

Please check more info in Rundeck documentation at: http://rundeck.org/1.6.2/manual/job-options.html#prompting-the-user