Lab review

modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc

@@ -142,6 +142,38 @@ sh-5.3$ nproc
 32
 sh-5.3$ 
 ----
-
++
 NOTE: If you deploy a container with limits (not just requests, but limits) and `active_processor_count` (jcmd or java -XshowSettings:system) returns that limit, the application is correctly container-aware. 
 Otherwise, in case it returns the host values, this indicates the application is likely not container aware (nproc shows host).
+
+. Set the resource limits on the deployment.
++
+[source,bash]
+----
+oc set resources deployment/my-java-app --requests=cpu=100m --limits=cpu=200m
+----
+
+. Connect to the newly running container.
++
+[source,bash]
+----
+oc get pods
+oc rsh <pod-name>
+----
+
+. Verify the CPU limits honored by the container and the Java application running inside it.
++
+[source,bash]
+----
+nproc
+jcmd 1 VM.info | grep active_processor_count
+----
++
+Example output:
+----
+sh-5.3$ nproc 
+1
+sh-5.3$ jcmd 1 VM.info | grep active_processor_count
+active_processor_count: 1
+sh-5.3$ 
+----

modules/hands-on-lab/pages/tuning-java-heap-settings-percentage-based-on-container-limits.adoc

@@ -53,7 +53,7 @@ Apply the following environment variables to your deployment:
 [source,bash]
 ----
 oc set env deployment/<deployment-name> \
-  JAVA_OPTIONS="-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"
+  JAVA_TOOLS_OPTIONS="-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"
 ----
 
 ### Step 3: Validate the Configuration

modules/introduction-to-containerized-java/pages/introduction-to-containerized-java.adoc

@@ -12,4 +12,4 @@ Key aspects include:
 * **Cgroup Detection:** Leveraging kernel-level control groups to monitor and manage resource availability accurately.
 * **Operational Efficiency:** Simplifying deployments by ensuring the JVM aligns its internal memory and thread management with defined container resource limits.
 
-This course is fully based on the current OpenJDK implementation and the article https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4[How to use Java container awareness in OpenShift 4].
+This course is fully based on the current OpenJDK implementation and the article https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4[How to use Java container awareness in OpenShift 4, window=_blank].

modules/openshift-and-kubernetes-integration/pages/configuring-limits-and-requests-in-red-hat-openshift.adoc

@@ -72,11 +72,19 @@ kind: Deployment
 metadata:
   name: java-resource-demo
 spec:
+
+  selector:
+    matchLabels:
+      app: java-resource-demo
+
   template:
+    metadata:
+      labels:
+        app: java-resource-demo
     spec:
       containers:
-      - name: java-app
-        image: registry.access.redhat.com/openjdk/openjdk-11-rhel8
+      - name: java-resource-demo
+        image: quay.io/hummingbird/openjdk:latest
         resources:
           requests:
             memory: "256Mi"
@@ -97,10 +105,15 @@ oc rsh <pod-name>
 +
 [source,bash]
 ----
+# FIXME: The below file is not found in the container
 $ cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
 # This will return 100000 (100ms), confirming the 1000m CPU limit.
-$ jcmd VM.info
-...
+$ jcmd 1 VM.info | grep active_processor_count
+----
++
+Example Output:
++
+----
 active_processor_count: 1 <-- shows 1 CPU
 ----
 
@@ -109,6 +122,20 @@ active_processor_count: 1 <-- shows 1 CPU
 [source,bash]
 ----
 java -XshowSettings:vm -version
-jcmd VM.info
 ----
-*Look for the output related to `MaxHeapSize` and `ActiveProcessorCount`. You will notice these values are derived from the limits, not the requests.*
++
+Example output:
++
+----
+VM settings:
+    Max. Heap Size (Estimated): 123.75M
+    Using VM: OpenJDK 64-Bit Server VM
+
+openjdk version "25.0.4.1" 2026-08-18
+OpenJDK Runtime Environment (Red_Hat-25.0.4.1.1-0) (build 25.0.4.1+1)
+OpenJDK 64-Bit Server VM (Red_Hat-25.0.4.1.1-0) (build 25.0.4.1+1, mixed mode, sharing)
+----
+
+FIXME: Limit is set to 512Mi but the heap size displayed is 123.75M. Output contradicts the below explanation.
+
+*Look for the output related to `Max. Heap Size` and `active_processor_count`. You will notice these values are derived from the limits, not the requests.*

modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc

@@ -106,7 +106,7 @@ spec:
           image: quay.io/hummingbird/openjdk:latest
 
           env:
-            - name: JAVA_OPTS_APPEND
+            - name: JAVA_TOOL_OPTIONS
               value: "-XX:NativeMemoryTracking=summary"
 EOF
 ----
@@ -171,6 +171,7 @@ To ensure your configuration is resilient, verify that your application does not
 +
 [source,bash]
 ----
+## FIXME: The below path is not found in the container.
 cat /sys/fs/cgroup/memory/memory.limit_in_bytes
 ----
 

modules/risks-and-memory-management/pages/risks-and-memory-management.adoc

@@ -10,6 +10,7 @@ When deploying Java in containerized environments, improper memory configuration
 *   **Non-container aware allocation:** Allocating a certain percentage for container, but not benchmarking/tracking non-container aware components inside the Java application. For example, jemalloand glibc's malloc that are below the JVM and are both not container aware.
 
 **Best Practices:**
+
     *   Prioritize container-aware JVM settings over manual heap overrides to allow for dynamic scaling.
     *   Benchmark application memory usage to determine the optimal ratio between heap and off-heap requirements.
     *   Avoid configurations that ignore cgroup limits, as these bypass the self-tuning capabilities of modern JDKs.

modules/troubleshooting-and-tooling/pages/analyzing-container-limits-and-resource-utilization.adoc

@@ -47,6 +47,7 @@ When analyzing resource constraints, follow these steps:
     *   **Non-container-aware:** Avoid using legacy `top` or `free` commands inside the container, as they often report host-level data rather than container-constrained data.
 
 == Hands-on Activity: Inspecting JVM Resource Awareness
+FIXME: This can be general instructions and not hands-on activity to be followed by learner.
 
 In this activity, you will verify if your currently running pod is correctly interpreting its cgroup limits.
 

modules/troubleshooting-and-tooling/pages/java-diagnostics-jcmd.adoc

@@ -57,6 +57,7 @@ jcmd <PID> VM.native_memory summary
 4.  **Verification:** Compare the output of `GC.heap_info` against your pod's `resources.limits.memory` to verify if the JVM is respecting the container's memory boundaries.
 
 == Hands-on Lab: Inspecting JVM Resources
+FIXME: Can this also be general instructions instead of hands-on activity?
 
 In this exercise, we will verify the JVM's memory awareness.