In this Ignition 7.8.1 trace, the gateway starts a Mobile client VM with Java, the process exits with code 1, and initialization times out after 10 seconds. The recorded workaround was to correct the Mobile client Java path on the gateway to Java 8 and raise client memory from 256 MB to 512 MB.
What does the gateway trace show along the request path?
The request reaches the gateway’s Mobile initialization path, which asks the VM manager to create a client process. That process must start successfully before the gateway can complete VM initialization for the request. The trace shows the sequence stopping at process startup, before the gateway reports a timeout.
| Time | Trace reading | What it tells you |
|---|---|---|
| 9:48:58 AM |
VMManager starts one client VM with java and -Xmx256M. |
The gateway attempted to launch a Java process; the configured heap in this launch was 256 MB. |
| 9:48:58 AM | Client VM exited unexpectedly with code 1. |
The new process terminated before initialization completed. This is the first failure to investigate. |
| 9:48:59 AM |
VMManager reports waiting 10 seconds for a new client VM and timing out. |
The timeout is the consequence seen by the request path; it follows the process exit. |
| 9:48:59 AM |
MobileDataServlet logs Timeout waiting for new VM during mobiledata/initvm. |
The servlet reports that the requested VM was not ready within its wait period. |
Follow this order when troubleshooting: gateway’s Java executable configuration, the client process exit, the local callback path, and then the client heap setting. A timeout message alone does not identify which startup condition failed.
Does the gateway point to the intended Java 8 installation?
Read the Java executable path configured for the Mobile client on the gateway, then compare it with the Java 8 installation actually present on that gateway machine. The installation reported Java 1.8.0_73, but the trace’s launch command begins with java, not a fully qualified executable path. The version report therefore does not, by itself, show which Java executable the child process resolved.
| Reading | Interpretation | Next check |
|---|---|---|
| Configured path points to the intended Java 8 executable | Proceed to the child-process exit and callback checks; verify the launch uses that executable. | Inspect the next startup trace. |
| Path is missing, stale, or points to a different Java installation | The client VM may start with an unintended runtime or fail to launch as expected. | Set the Mobile client Java path to the Java 8 path on the gateway and retry. |
| Actual executable or path cannot be identified | The reported Java version is not enough to resolve the runtime used by this process. | Read the gateway’s Mobile client setting and the executable path used for the next launch. |
Do not substitute a workstation’s Java path: the trace shows the gateway launching the VM, so the path must resolve on the gateway host. The report lists Ignition 7.8.1, Java 1.8.0_73, Vision 8.8.1, and Mobile 3.8.1. Preserve those as the recorded versions while diagnosing; the supplied trace does not establish that any one version pairing caused the failure.
Does the new client process exit before the timeout?
Read the VM manager entries immediately before the servlet timeout. In this case, the client exits with code 1 at 9:48:58 AM, while the servlet reports the timeout at 9:48:59 AM. That ordering makes the exit the primary branch to investigate, rather than treating the later servlet exception as the first cause.
- If the VM exits: inspect the gateway log entries around the launch for the underlying startup error, then verify the configured Java executable and the Mobile client settings. The numeric exit code alone does not identify the cause.
- If the VM remains running but initialization still times out: continue to the callback-path check; startup may have progressed but the gateway may not be completing the local initialization exchange.
- If no launch entry appears: check whether the request reached Mobile initialization and whether the VM manager attempted to create a process before pursuing network-path causes.
The trace contains a Java launch command with the Ignition launch client JAR, Mobile client JARs, and com.inductiveautomation.mobile.MobileMain. Use the next launch’s complete command and adjacent gateway log entries to compare behavior; do not infer the cause from the exception stack alone.
Does the gateway complete the local callback path?
The launch command includes -Dmobile.callback.interface=localhost and -Dmobile.callback.port=45900. These values describe a local callback target associated with the client VM startup. They do not show that a listener accepted a connection or that initialization completed.
| Trace value | Check | Branch |
|---|---|---|
localhost |
Confirm the callback interface remains local to the gateway host and inspect logs for a callback or initialization completion. | If the child VM exits first, return to the Java/process-startup branch. If it remains running without completion, investigate callback handling on the gateway host. |
45900 |
Compare the port in the actual launch command with gateway-side startup or callback diagnostics for that attempt. | If a different port appears, follow the value in the current launch rather than assuming the trace’s port is universal. If the process starts but no callback completes, inspect local port availability and host security controls. |
Do not begin by changing external routing or firewall rules based only on this trace. The logged callback interface is localhost, and the visible failure occurs during gateway-side VM startup. First determine whether the process remains alive and whether local initialization completes.
Is the configured client heap adequate for startup?
The launch shown uses -Xmx256M. The reported corrective change was to raise Mobile client memory to 512MB. This gives the client VM a larger maximum heap, but it does not repair a bad Java executable path or a process that exits for another reason.
| Setting evidence | Action | Interpretation |
|---|---|---|
Trace shows -Xmx256M
|
Read the Mobile client memory setting and compare the next launch command. | This is the memory allocation shown for the failed attempt. |
| Configured memory is 256 MB | Try the reported 512 MB client-memory setting, then capture the launch trace again. | If the process now stays alive and initialization completes, the memory change addressed this startup case. |
| Memory is already 512 MB or higher, but the process exits | Prioritize the exit details and Java path; retain the exact new command and adjacent logs. | Increasing memory again is not a substitute for identifying the exit cause. |
Compare the actual Java launch command before and after the change. The heap option and executable selection are separate settings: confirm both rather than assuming a memory adjustment changed the runtime path.
How do you apply the resolving settings and verify startup?
Apply the two reported changes as separate checks so the next trace shows which setting changed the result. Use the gateway’s Mobile client configuration, not a Java setting on the mobile device or an operator workstation.
- Record the current Mobile client Java path and memory setting, plus the current gateway log around one failed initialization attempt.
- Set the Mobile client Java path to the Java 8 executable installed on the gateway. Confirm the path exists on that host.
- Set the Mobile client memory to
512MB, the value reported for the corrective change. - Retry Mobile initialization and capture the new gateway log, including the complete VM launch command and surrounding
VMManagerand servlet entries. - Compare the new command with the prior command: verify the intended Java executable is used and check whether the heap option changed from
-Xmx256M. - Follow the new event order. If the VM no longer exits and the initialization request completes without
Timeout waiting for new VM, the startup path is restored. If code1or the timeout remains, use the adjacent startup error and callback diagnostics to choose the next branch rather than repeating changes blindly.
For the final check, verify that a fresh Mobile initialization completes and the gateway log contains no corresponding VM exit or Timeout waiting for new VM.
FAQ
Why does Ignition Mobile report “Timeout waiting for new VM”?
The gateway’s Mobile initialization request waits for a client VM, but the traced VM exited with code 1 before initialization completed. The servlet timeout follows that process failure in the logged sequence.
Why does the Mobile VM use the wrong Java version?
The reported Java version does not identify the executable resolved by the gateway’s launch command. Check the Mobile client Java path on the gateway and point it to the installed Java 8 executable.
Why does increasing Mobile client memory help?
The failed launch shows -Xmx256M, and the reported corrective setting was 512MB. A larger heap can address a memory-limited startup, but it will not fix a bad Java path or another process-startup error.
How do I verify the Ignition Mobile VM timeout is fixed?
Retry initialization and confirm the gateway starts the client VM, the process does not exit unexpectedly, and the request completes without Timeout waiting for new VM. Check the fresh trace’s Java executable and heap option as the final verification.