OpcUaClient: decide whether the 3 s PerEndpointConnectTimeout default is too tight for a first secure connect #912

New Issue

2026-11-13T13:48:26-05:00

dohertj2 commented

2026-11-13 13:48:26 -05:00

Follow-up from #910 (fixed in 73132b7d, merged 79371402).

OpcUaClientDriverOptions.PerEndpointConnectTimeout defaults to 3 s (src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.OpcUaClient.Contracts/OpcUaClientDriverOptions.cs:56). The budget covers endpoint discovery and client-side work: loading the application certificate, validating the server certificate, and the asymmetric crypto of a Basic256Sha256 OpenSecureChannel + CreateSession.

#910 showed a cold test process on a loaded host exhausting those 3 s against a healthy opc-plc (opc-plc log: secure channel created 3 s after discovery, client closed it 48 ms later). The #816 tests now use 15 s; the browser integration tests already use 10 s. Production still uses 3 s.

Production exposure: a freshly started or heavily loaded OtOpcUa node can time out its first secure connect to a healthy upstream. It recovers via the reconnect watchdog, and since #910 the error says TimeoutException: The connect did not complete within PerEndpointConnectTimeout (3 s) rather than BadRequestInterrupted. Cost: delayed first data and a spurious fault/health transition at startup, worse with many OpcUaClient drivers starting at once.

Trade-off: the budget is per endpoint so failover across a redundant endpoint list moves on quickly from a dead endpoint. Raising it slows failover past an unreachable endpoint by the same amount.

Options:

raise the default (e.g. 10 s) and document the failover cost;
keep 3 s for the TCP/discovery phase but give the secure-channel + CreateSession phase its own, larger budget;
keep 3 s and only document it (per-driver override already exists).

Decide, then update docs/drivers/OpcUaClient.md accordingly.

Follow-up from #910 (fixed in `73132b7d`, merged `79371402`). `OpcUaClientDriverOptions.PerEndpointConnectTimeout` defaults to **3 s** (`src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.OpcUaClient.Contracts/OpcUaClientDriverOptions.cs:56`). The budget covers endpoint discovery **and** client-side work: loading the application certificate, validating the server certificate, and the asymmetric crypto of a Basic256Sha256 OpenSecureChannel + CreateSession. #910 showed a cold test process on a loaded host exhausting those 3 s against a healthy opc-plc (opc-plc log: secure channel created 3 s after discovery, client closed it 48 ms later). The #816 tests now use 15 s; the browser integration tests already use 10 s. Production still uses 3 s. **Production exposure:** a freshly started or heavily loaded OtOpcUa node can time out its first secure connect to a healthy upstream. It recovers via the reconnect watchdog, and since #910 the error says `TimeoutException: The connect did not complete within PerEndpointConnectTimeout (3 s)` rather than `BadRequestInterrupted`. Cost: delayed first data and a spurious fault/health transition at startup, worse with many OpcUaClient drivers starting at once. **Trade-off:** the budget is per endpoint so failover across a redundant endpoint list moves on quickly from a dead endpoint. Raising it slows failover past an unreachable endpoint by the same amount. **Options:** - raise the default (e.g. 10 s) and document the failover cost; - keep 3 s for the TCP/discovery phase but give the secure-channel + CreateSession phase its own, larger budget; - keep 3 s and only document it (per-driver override already exists). Decide, then update `docs/drivers/OpcUaClient.md` accordingly.

dohertj2 added the driver/opcuaclient type:followup priority:p3 labels 2026-11-13 13:48:26 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#912