...
Step 5 — verify it is running
There is no jcmd in the bundled JRE, so verification is by observation:
1. tomcat\logs\gc.log exists and is growing.
2. tomcat\logs\jfr\ contains one or more .jfr chunk files within a minute or two of startup.
3. The JFR startup message appears in the service's stdout log — normally tomcat\logs\commons-daemon*.log or tomcat\logs\stdout*.log, depending on how procrun is configured. A failure to start the recording is reported in the same place.
If tomcat\logs\jfr\ stays empty, check that the directory from Step 1 was created and that the service account can write to it. If the service now fails to start at all, an option is malformed — revert Step 3 and repeat Step 2.
Overhead
Published and commonly-measured figures. These are not measured against DualShield; treat them as guidance, and measure on a representative load test if a customer needs a committed number.
- JFR with settings=default — Oracle states under 1%; field measurements typically 0.5–1%.
- GC logging — negligible, under 0.5%. The cost is buffered file writes of a few KB/s.
- Heap dump on OOM — exactly zero until it fires. When it fires it pauses the JVM for roughly the time needed to write the live heap, on an OutOfMemoryError that was already unrecoverable.
...
Results:
Here is a plain-English breakdown of the results you will see once continuous JVM diagnostics are running on your DualShield server:
A continuous record of what the server was doing right up until a crash or freeze. Instead of losing all clues when a high-CPU incident forces a restart, the Java Flight Recorder (JFR) keeps a rolling 24-hour history of execution samples, memory garbage collection, locks, and I/O saved directly to your hard drive.
Exact identification of the code causing high CPU. By opening the recording files (jfr) in JDK Mission Control, you can drill down into the method profiling to pinpoint the exact internal method or loop that was burning up your CPU resources during an incident.
Immediate separation of memory issues from performance bottlenecks. The separate garbage collection log (
gc.log) lets you look at trends within seconds to easily distinguish whether a slowdown is a genuine hot loop or a garbage-collection death spiral.Automatic snapshots if the server runs out of memory. If the service ever throws an
OutOfMemoryError, the JVM will automatically capture and dump the entire live heap to disk the exact moment it happens, letting you inspect what filled up the memory.Easy retrieval through the console. Because the key summary and exit files are written straight into the main Tomcat log directory, you can download them directly through the DualShield Administration Console (DAC) system log list without needing RDP or file share access.
- You can view OutOfMememory errors under C:\Program Files\Deepnet DualShield\tomcat\logs\. remeberm, these files are only created when system runs out of memory
Collecting after an incident
Ask the customer for the Tomcat log folder, zipped — the same folder they already send for any other DualShield issue:
C:\Program Files\Deepnet DualShield\tomcat\logs{color}
Exclude *.hprof from that zip. A heap dump is as large as the live heap and will make the archive unsendable. Ask for it separately, and only if the case is an OutOfMemoryError.
This works after a restart or reboot. JFR writes chunks to the repository continuously, so the last 24 hours survive a hard kill. das-exit.jfr is additionally written on a clean shutdown.
Open the .jfr files in JDK Mission Control. Start with Method Profiling for a hot loop, and the GC log or the Garbage Collections page for a collection death spiral.
Capturing during the incident, without jcmd
The bundled JRE has no jcmd, jstack or jmap, so the usual on-demand commands are not available on a customer machine. What is available:
- Thread dump — use the product. The CPU Load Monitor task in DAC writes a full thread dump plus per-thread CPU times from inside the JVM, using ThreadMXBean. It needs no external tool. Run it on demand from the task list, or leave it enabled on a schedule. Output goes to the configured export directory (dual/export/directory), not to tomcat\logs.
- JFR — rely on the continuous recording. No dump command is needed. The chunks in tomcat\logs\jfr\ already contain the incident, and das-exit.jfr is written on clean shutdown.
...
- jcmd must run as the same account as the DualShield service. That is usually LocalSystem, so an ordinary elevated prompt will not attach — run it as SYSTEM, for example with PsExec -s.
- The JDK's major version should match the bundled runtime.
...
Downloading through DAC
Because these files land in Tomcat's log directory, DAC's system log file list picks them up, so support can retrieve them through the console without RDP or file share access. The listing is non-recursive and files-only, which is why gc.log, das-exit.jfr and incident.jfr are written to the log directory itself rather than into the jfr subdirectory — the rolling chunk files in jfr\ are not listed and still need collecting by hand.
Viewing log files requires the SystemFile:view permission.
Rolling back
Remove the five options from the service configuration and restart. Nothing else is left behind. Existing .jfr and gc.log files can be deleted freely once a case is closed.
Notes
...
- .