On an Ignition 8.3 gateway, a newly installed module does not run until the gateway restarts. This is intentional: hot loading was removed in 8.3.0. Module changes are staged, the gateway posts a banner counting the changes waiting on a restart, and one restart applies all of them. Plan module work as a batch with a single restart window rather than treating the restart as a fault.
Why does Ignition 8.3 hold a new module until the gateway restarts?
The restart requirement comes from how the Java runtime loads module code. Each Ignition module ships its own classes, and the gateway loads them through class loaders layered over the platform. Hot loading adds and removes those class loaders while the JVM keeps running. Several things go wrong in that model:
- Stale class references. Code in other modules or the platform can keep references to classes from an unloaded or replaced module. The old class loader cannot be garbage-collected, so two versions of the same class can coexist, and objects created under the old version fail casts or type checks against the new one.
- Orphaned threads and static state. A module that does not fully shut down its executors, listeners, or static singletons leaves them running against a torn-down context.
- Startup ordering races. When modules depend on each other, loading one mid-run means its dependencies and dependents are already in arbitrary lifecycle states.
On earlier versions these conditions showed up as modules that had to be restarted individually to clear odd behavior after an install or update. In 8.3 the full module list is known at gateway startup, so class loaders are built once, dependencies are resolved in a single pass, and the race conditions tied to swapping code in a live JVM are removed. The price is a restart for every module add, update, enable, disable, or uninstall.
What path does a module change take from upload to running code?
Trace one module install through the gateway:
| Hop | What happens | Module state |
|---|---|---|
| 1. Operator action | Module is uploaded, updated, enabled, disabled, or marked for uninstall from the gateway web interface | Change recorded, not active |
| 2. Gateway staging | Gateway holds the change against the current running module set | Pending restart |
| 3. Notification | After a short delay, a banner appears showing how many module changes are waiting on a gateway restart; hovering over part of the banner lists the affected modules | Pending restart |
| 4. Restart trigger | Restart issued directly from the banner (or by restarting the gateway service) | JVM shutting down |
| 5. Gateway startup | Module list enumerated, class loaders built, dependencies resolved, module startup runs | Running with new set |
A module that appears installed but is not executing is almost always sitting at hop 2 or 3. The banner is the diagnostic: if it shows a pending count, the change has not reached the runtime yet.
Restart per module or once per batch: which approach wins?
Multi-module suites make this decision matter. A Sepasoft installation, for example, can be five separate modules that are usually updated together. The staging model does not require a restart per module; any number of changes can be queued and applied with one restart.
| Criterion | Restart after each module | Stage all changes, restart once |
|---|---|---|
| Number of gateway outages | One per module (five for a five-module suite) | One |
| Intermediate mixed-version states | Yes: suite runs partially updated between restarts | No: all modules start at the new versions together |
| Dependency resolution | Repeated against partially updated sets | Resolved once against the final set |
| Client and device reconnects | Repeated | Once |
| Isolating a faulty module | Easier: one change per start | Needs log review to find the failing module |
Recommendation: stage the full set of changes and restart once. Restart per module only when troubleshooting, when you need to identify which module in a set fails to start.
How do you stage and apply a batched module change?
- Collect every module file needed for the change set, including all modules of a vendor suite that must move together. Check each module's compatibility with the running 8.3 platform version in the vendor's release notes before uploading.
- Back up the gateway before making module changes so you can roll back to the previous module set.
- From the gateway web interface, perform every add, update, enable, disable, and uninstall in the set. Do not restart between them.
- Wait for the restart banner. Confirm the count matches the number of changes you made.
- Hover over the banner to list the pending modules. Verify every intended module appears and no unintended one does.
- Notify operators and schedule the window: all Perspective and Vision sessions disconnect, device connections drop, and tag scanning and history collection pause while the gateway is down.
- Trigger the restart from the banner.
What goes wrong around the restart on a production gateway?
| Symptom | Cause | Fix |
|---|---|---|
| New module installed, features absent | Change staged, restart not yet performed | Check the banner; restart to apply |
| Banner count lower than expected | One change was not accepted (upload failed, license or compatibility rejection) | Hover the banner list, redo the missing change before restarting |
| Suite behaves inconsistently after update | Suite updated across multiple restarts, leaving mixed versions for a period, or one module skipped | Verify all suite modules show the same target version; stage any stragglers and restart once |
| Module faulted after restart | Missing dependency or platform version mismatch detected at startup | Read the gateway logs for the module startup error; install the dependency or correct version, restart |
| Unplanned outage during production | Restart clicked from banner at the wrong time | Treat the banner restart as a full gateway restart; only trigger it inside an approved window |
On redundant gateway pairs, plan the module change and restart for both nodes so the primary and backup run the same module set; a mismatched module list between nodes defeats failover.
How do you confirm every staged module loaded?
- After the gateway returns, confirm the restart banner is gone. A banner still present means a change remains pending.
- Open the module list and check each changed module: installed modules show running at the new version, disabled modules show disabled, uninstalled modules are absent.
- Scan the gateway logs from the startup period for module load errors or dependency warnings.
- Check device connections and tag quality: drivers reconnected and tags returning good quality.
- Open a client session and exercise at least one function provided by each new or updated module, confirming the new version's behavior is live.
FAQ
What happens if I install a module in Ignition 8.3 and never restart the gateway?
The change stays staged and the module does not run. The banner keeps showing the pending count until a gateway restart applies it.
What happens if I update five modules in a suite: do I need five restarts?
No. Stage all five updates, confirm the banner count and module list, then restart once; all modules start together at the new versions.
What happens if I disable a module in Ignition 8.3?
Disabling is also staged. After a short delay the banner shows it as a change waiting on restart, and the module keeps its current state until the gateway restarts.
Why did Ignition remove module hot loading in 8.3?
Loading and unloading module code in a running JVM caused class loader problems, race conditions, and instabilities that often needed module restarts to clear. Knowing the full module list at startup avoids those failures.
What happens if I click restart on the module banner during production?
The full gateway restarts: clients disconnect, device connections drop, and data collection pauses until startup completes. Trigger it only inside a planned maintenance window.