Ignition Vision Client Bad_Stale Reconnects: Fix One PC

Where does the request stop?

Follow the packet. A Vision client polls its gateway on a fixed schedule. The request leaves the client JVM, passes through the Windows TCP/IP stack, the NIC driver, the physical adapter (onboard, dock, USB-C dongle, or Wi-Fi), the access switch, and any routed hops, and ends at the gateway's HTTPS listener. When one client of twelve drops out and the other eleven stay connected, the shared hops are healthy: the gateway, its listener, and the core network. The fault sits on the part of the path used only by the failing client.

The installation in this case:

Redundancy was configured but not working. That is a separate fault, covered below. It does not produce this symptom.

What does the client log show, event by event?

Read the client console log as a timeline, not as a pile of stack traces. One full cycle, reconstructed from the log:

Every symptom downstream of 12:39:40.130 follows from one event: a TCP connect that did not complete. The Bad_Stale quality, paused scripts, failed history queries, and resubscription are all consequences. Fix the connect timeout and the rest goes away.

Why does "Connect timed out" point below the application layer?

Layer one first. The stack trace ends in java.net.SocketTimeoutException: Connect timed out, thrown from sun.nio.ch.NioSocketImpl.timedFinishConnect. It was reached through SSLSocketImpl.connect and HttpsClient, and was triggered by GatewayInterface.ping called from GatewayTagInterface.runPoll.

That chain tells you exactly how far the request got:

• Connect timeout. The TCP three-way handshake (SYN, SYN-ACK, ACK) did not finish within the client's connect timeout. No TLS handshake happened, no HTTP request was sent, and the gateway application never saw the attempt.
• Read timeout (not seen here). The TCP connection opened, the request was sent, and the gateway was slow to answer. That is the signature of an overloaded gateway, a blocked servlet thread, or a slow database behind a query.

The operating system kernel completes the TCP handshake, not the Ignition application. A gateway at under 5% CPU completes handshakes in microseconds. A handshake that never completes means SYN or SYN-ACK packets were lost or held somewhere on the path. With eleven other clients connected, that somewhere is almost always one of the following:

• The client NIC entering a low-power state or losing link.
• A NIC driver stall or adapter reset.
• A dock or USB Ethernet adapter re-enumerating.
• A Wi-Fi roam or power-save doze.
• A filter driver (VPN client, endpoint security) holding outbound connections.
• A faulty patch cable or switch port used only by that client.

A dead cable or wrong route stays broken. A path that disappears and returns in about a second, on a repeating cycle, behaves like a power-management or driver event on the host.

Why do sparkline charts throw "No session found" after the link returns?

A Vision client holds an authenticated session on the gateway. When the connection drops, the client starts its reconnect thread. When the path returns, the client learns the old session is gone (Session no longer valid.) and logs back in. The log shows the client re-authenticating as user monitor with Roles: [] and Security Zones: null.

Between the path returning and the re-login completing, bindings keep firing on their poll schedule. Each sparkline in the log is bound to a tag history query:

• The binding polls every 5000 ms (@5000ms).
• Example path: prov:default:/tag:sensors/cloud/oven_blue/tempc.

Any query sent in that window goes out on the dead session. The gateway rejects it with No session found. You must re-login. (QueryTagHistory). The stack trace runs through TagHistoryCache, SubCache, and StandardCacheBucket, so the client-side history cache tried to fill a bucket and the gateway call failed.

These errors are secondary. Do not chase them in the history provider, the database, or the chart configuration. The same applies to Subscription crc mismatch, will resubscribe.: the client detects that its subscription set no longer matches the gateway's view after the new session and rebuilds it. That is normal recovery behaviour.

Is the red client diagnostics graph the cause or a consequence?

The client diagnostics Performance tab turned red at the same moments the log recorded reconnects. The decision rule is order in time:

A connect timeout comes from the socket layer. Even a starved JVM would normally show a read or response delay, not a failed handshake. Treat the red trace as a consequence unless the resource graphs lead the timeout.

Does the broken redundancy explain the reconnects?

No. Two separate observations get conflated here:

• The master shows activity level "Active". That is the normal state of a healthy master. It does not mean a failover occurred. Nothing in the client log shows a switch to a backup address; every reconnect returns to the same gateway.
• Clients do not list a backup gateway, and a forced failover leaves clients dead because the backup does not respond. This is a real redundancy fault. Clients have no backup address to move to, and the backup gateway is not serving. It belongs with whoever owns the redundancy configuration (here, the integrator).

Redundancy misconfiguration affects every client equally. It cannot make one laptop out of twelve lose its TCP handshake every other minute while the master stays Active. Fix it on its own schedule, and keep it out of this diagnosis.

Which fixes are on the table, and how do they compare?

Why isolate the client hardware first?

Isolate the client hardware first because the evidence pattern points there:

• Only one host fails.
• It is the only host of its kind: a new Windows 11 laptop.
• The failure is a TCP connect timeout, so the application never received the attempt.
• The gateway is idle, and the other eleven clients hold their sessions.

Swap tests on that host split the path into halves quickly, and each test needs no change to the production gateway or project.

The OS difference (Windows 11 against Windows 10 and Ubuntu) is a correlation, not the mechanism. Here the cause traced to the laptop's hardware and drivers, not to Windows 11 as such. New high-end laptops commonly ship with the following, all of which can drop a connection attempt for a second or so:

• Aggressive NIC power management.
• Docking stations or USB-C Ethernet adapters with their own firmware.
• Modern standby behaviour.
• OEM network utilities or security agents.

How do I isolate the fault on the client?

Collect timestamps first, then change one variable at a time. Keep the Vision client running during every test so its log records reconnects on the same clock as your probe.

1. Confirm the gateway port. The stack shows HTTPS (HttpsClient, SSLSocketImpl). Read the host and port from the gateway address this client launches against, in the Vision client launcher configuration. Do not assume a default.
2. Run a timestamped TCP connect probe from the laptop to that host and port (script below). A failed TCP connect in the probe at the same second as a client Connect timed out confirms the problem is below Ignition.
3. Swap the physical path. Plug a known-good Windows 10 client into the laptop's exact cable, dock, and switch port, then run the Vision client there. Plug the laptop into a port and cable that a healthy client uses. If the fault follows the laptop, the cable, port, and switch are cleared.
4. Swap the adapter. If the laptop connects through a dock or USB-C Ethernet dongle, connect straight to the onboard NIC, or the reverse. If it is on Wi-Fi, run the test wired. A fault that disappears with one adapter identifies the hardware or driver at fault.
5. Read the Windows System event log at the recorded timestamps. Look for network adapter disconnect, reset, or link-state events from the NIC driver, and for power-state transitions. Events that line up to the second with the client reconnects close the case on the adapter.
6. Disable NIC power saving. In Device Manager, open the adapter's Power Management tab and clear the option that lets Windows turn the device off to save power. On the Advanced tab, disable energy-efficient Ethernet and similar power-saving properties; names vary by NIC vendor, so read the list the driver exposes. Set the Windows power plan so the network adapter is not throttled while plugged in.
7. Update or roll back the NIC and dock drivers and firmware using the laptop manufacturer's packages, not only the generic driver Windows Update installs. Apply the dock firmware if a dock is in the path.
8. Test filter drivers. If site policy allows, temporarily disconnect the VPN client or pause the third-party network filter or endpoint agent and repeat the probe. A filter that holds outbound SYNs produces exactly this connect-timeout signature.
9. Reinstall the Vision client launcher only if the probe shows clean TCP connects while the Vision client still logs Connect timed out. That split points back into the client software stack.

What probe script gives a timeline to match against the client log?

Run this in PowerShell on the failing laptop. It opens a raw TCP connection to the gateway's HTTPS port about once a second and logs the result with milliseconds. Replace the host and port with the values from step 2.

Read the result against the client log:

It is not the Ignition client's connect timeout.

How do I verify the fix?

1. Search the client console log over the same window. Pass when there are no Connect timed out, no Changing connected quality to 'Bad_Stale', no Starting reconnect thread., and no No session found. You must re-login. (QueryTagHistory) entries.
2. Watch the client diagnostics Performance tab for the same period. Pass when there are no red excursions.
3. Undo the one change that made the difference (re-enable the power-saving option, go back to the old adapter, or reinstate the old driver) for a short test window. Confirm the drops return, then reapply the fix. A reproducible on/off result proves the root cause. Record that setting in the laptop build standard so a reimage or driver update does not bring it back.

FAQ