Ignition Perspective 'Unable to Save View' Timeout Fix

The Unable to save view config in 60 seconds error means the Designer missed a deadline. It does not mean the view is corrupt. On save, the Designer waits up to 60 s for the embedded Perspective session to return the finalized view configuration. When the Designer JVM runs out of heap (java.lang.OutOfMemoryError: Java heap space), that response is dropped and the wait always runs the full 60 s. Raise the Designer memory allocation from the Gateway settings and relaunch the Designer. On the affected install, going from 1 GB to 4 GB cleared the fault. If no OutOfMemoryError comes before the timeout, the problem is timing, usually a save issued while a view is still reloading after a bulk edit.

Log Signatures and the Quantity Behind Each

Four log entries appear together in the Designer Output Console. Each one records a different quantity passing a limit, so read them in time order before you change anything.

The timestamps in the captured log give the sequence:

• 22:54:46.191: Save finished in 337ms.

The number that matters is the gap between the OutOfMemoryError and the timeout. If the OOM comes first and the timeout lands about 60 s later, the minute of freeze was spent waiting on a dead request. This is memory, not logic.

Gateway Memory Versus Designer Heap

The Gateway status page and the Designer report on two separate JVMs. On the affected system, Gateway CPU swung between 30% and 70% and Gateway memory between 700 MB and 1450 MB. Those figures describe the Gateway service's heap. A Gateway heap that climbs and then drops is normal garbage-collection behavior. It says nothing about the Designer, which is a separate Java process on the engineering workstation with its own maximum heap.

The OOM in the log came from the Designer's IPC Memory Reader Thread, which lives in the Designer process. A Gateway with plenty of free memory can still serve a Designer that is starved at 1 GB. Diagnose Designer heap from the Designer's own log and its own process. Gateway status graphs cannot settle it.

The Ignition free trial does not cap memory either. Its only limit is the two-hour runtime; otherwise the trial is fully functional. A trial Gateway and a licensed Gateway fail this save the same way when the Designer heap is undersized.

Save Path Through the Embedded Perspective Session

Saving a Perspective view involves more work than writing a file, which is why this path is sensitive to both heap and timing. The Designer is a Java desktop application. Views are edited inside an embedded web browser engine that runs a live Perspective session. On save, the call stack shows this sequence:

1. IgnitionDesigner.handleSave calls commitAll. This notifies the Perspective module hook (DesignerHook.notifyProjectSaveStart) and the view workspace (ViewWorkspace.notifyProjectSaveStart).
2. TabbedResourceWorkspace.commitAll goes through every open view editor and calls ResourceEditor.commit on each.
3. For each view, ViewResourceEditor.getObjectForSave calls into the embedded browser session. The session finalizes its internal state, renders a preview thumbnail, and serializes the view config back across the inter-process link.
4. The Designer blocks on a CompletableFuture.get with a timeout until that reply arrives or the deadline expires.
5. Once every editor has committed, the Designer writes the resources to the Gateway, which is the Save finished in N ms line.

In 8.1 this exchange is synchronous and runs on the main GUI thread. While step 4 waits, the Designer cannot repaint, respond to clicks, or accept keyboard input. That explains why a heap failure a fraction of a second into the save produces a full minute of apparent lockup.

The same commit also runs when you close a view tab. A second captured trace shows TabbedResourceWorkspace.close leading to ResourceEditor.commit and the same getObjectForSave timeout. Closing a dirty view is therefore a save event and can freeze the Designer in the same way.

Why the Heap Runs Out at Save Time

Steady-state Designer memory can look fine and still fail during a save, because the save adds a large, short-lived allocation on top of everything already loaded. The failed RPC response in the log is tagged serialized_message: "[...18450018]". If that figure is the payload length in bytes, the reply carrying the view config back from the session was about 18 MB. The JVM does not receive a payload of that size in one copy. It is buffered, decoded into strings, and parsed into an object tree, and each stage holds its own copy until the next stage finishes. Peak transient demand is therefore several times the raw payload size.

Add that peak to what is already on the heap: the project resource tree, every open view editor, tag browser caches, and component palettes. A 1 GB ceiling leaves little room. Whether the save succeeds depends on peak heap during the save, not the average between saves.

Several conditions push the peak higher:

• Many views open at once. commitAll round-trips every open, modified editor during a single save.
• Large views with deep component trees or large embedded data in props, which produce large serialized replies.
• Long Designer sessions in which open resources and caches have built up.

The 60-Second Deadline and ignition.perspective.designerSaveTimeout

The 60 s limit protects the Designer. Because the save blocks the GUI thread, a Perspective session that never replies would otherwise hang the Designer indefinitely. The timeout message replaced the older View Config is Undefined message and arrived together with changes to the Java-to-browser interop layer meant to prevent these stalls.

The dialog text suggests raising the deadline through the ignition.perspective.designerSaveTimeout Designer property. Whether that helps depends on which root cause you have:

The property is read by the Designer JVM, so it has to be passed to the Designer at launch as a Java system property (-Dignition.perspective.designerSaveTimeout=<value>), in whatever place your Designer Launcher accepts JVM arguments for that Gateway entry. Check the unit of <value> and the supported way to set it for your version in Inductive Automation's documentation or with their support team before relying on it. A wrong unit can turn a 60 s deadline into a few milliseconds or several hours.

Procedure: Raising the Designer Memory Allocation

1. Confirm the OOM. Open the Designer Output Console and look for java.lang.OutOfMemoryError: Java heap space on the IPC Memory Reader Thread in the second before the timeout. If it is missing, skip to the reload-window section.
2. Budget host RAM. The new maximum heap must fit in physical memory, alongside the embedded browser engine process, the operating system, and the Gateway if it runs on the same machine. On the affected system the Gateway alone ranged from 700 MB to 1450 MB. A heap that forces the OS to page makes every save slower and moves the failure from OOM to timeout.
3. Open the Gateway web interface and go to the Gateway Settings page. The Designer memory allocation is set there, because the Gateway supplies the launch parameters to Designers that connect to it.
4. Step the value up. On the affected project, 1 GB failed and 4 GB saved cleanly. Move one step at a time instead of jumping to the host's limit. Excess heap lengthens full garbage-collection pauses and takes memory from the browser engine.
5. Save the Gateway setting, then close every open Designer connected to that Gateway. JVM maximum heap is fixed when the process starts, so a running Designer keeps its old ceiling.
6. Relaunch the Designer from the launcher, open the same set of views that were open during the failure, and repeat the save that timed out.

Reload-Window Race After Find/Replace and Bulk Edits

A second failure mode produces the same 60 s timeout without any memory shortage. It was seen on a workstation with 32 GB of RAM and a Designer heap of 4096 MB. The Designer froze for about a minute, showed the timeout, and then saved normally on the next attempt. This fault is timing: the save request arrives while the Perspective session is rebuilding the view.

It can be reproduced in a new project:

1. Create a new Perspective view.
2. Add a Label component and set props.text to foo.
3. Right-click the view and choose Find/Replace selected Views.
4. Search for foo, click Find, and check that the label's props.text appears in the results.
5. Set the replacement to bar, click Replace All, and confirm.
6. The view briefly disappears and reloads. Press Ctrl+S while it is reloading, closing the Find/Replace window first if needed.

A save issued before the view disappears succeeds, and so does a save issued after it reappears. Only a save that lands inside the reload window freezes the Designer. The likely mechanism is contention between the Designer's save request and the Gateway/session-side reload, with both sides waiting on each other until the 60 s deadline breaks the stall. On large projects the reload after bulk edits takes much longer, even on well-equipped machines, so the window is wide enough to hit by habit.

Workaround: after any Find/Replace, bulk property edit, or other operation that forces a view reload, wait until the view has fully redrawn before saving or closing the tab. More heap does not shorten this window.

Verification

1. Save duration: after the fix, each save should log INFO designer.update-and-save -- Save finished in N ms with no preceding Timeout saving view. For scale, the save that followed the timeout on the affected system took 337 ms.
2. No heap failure: the Output Console should show no OutOfMemoryError across several saves with your normal working set of views open.
3. No watchdog dumps: no new NonResponsiveEdt-<date>_<time>.json files should appear in %USERPROFILE%\.ignition\cache\gw<gateway-address>_<port>\C0\. A new file means the GUI thread blocked again, even if the save eventually worked.
4. Peak heap headroom: attach a standard JDK monitoring tool such as JConsole or VisualVM to the Designer process, or use the Designer's diagnostics window. Watch used heap during a save of your largest view. If the peak stays well below the configured maximum, you have margin. If it touches the ceiling, the next larger view will fail again.
5. Close-tab path: modify a large view and close its tab without saving first. The implicit commit should finish without a freeze.
6. Bulk-edit path: run a Find/Replace, wait for the reload to finish, then save. The save should succeed on the first attempt.

Recurring Pitfalls

When to Stop and Escalate

Escalate once the Designer heap has confirmed headroom during saves, no OutOfMemoryError appears, and the freeze still happens outside any reload window. At that point, local tuning has nothing left to adjust. Open a formal case with Inductive Automation support. Attach the NonResponsiveEdt JSON stack dumps, the Designer log covering the full 60 s window, the Designer memory setting, and a minimal reproduction. That data is what their team uses to track and fix save-path defects.

FAQ