Configuration

Applies to Milo 1.2.0-SNAPSHOT. Source baseline 7faaf4f05, 2026-10-04.

This page lists the client and server settings that applications most often change and that commonly interact, with their defaults at this baseline. The linked API source is the complete reference. Configure everything on the builders before you create the runtime objects. Use one Milo version throughout the application, and settle endpoint, identity, and resource ownership first.

Client settings

These OpcUaClientConfigBuilder settings control endpoint selection, Session health, and request limits.

Setting	Unit and default	Effect and responsibility
setEndpoint	EndpointDescription	Select a discovered endpoint with the intended policy, mode, and token policies. Changing a hostname does not establish trust.
setSessionTimeout	Milliseconds; 120,000	Requested Session timeout. Inspect the server's revised value. This is not a per-operation timeout.
setRequestTimeout	Milliseconds; 60,000	Request deadline. A timed-out Write or Method call can leave the outcome unknown, so do not blindly retry non-idempotent work.
setKeepAliveInterval, setKeepAliveTimeout	Milliseconds; 5,000 each	Session health checking. Choose values for the expected latency and failures. These are separate from Subscription keep-alives.
setKeepAliveFailuresAllowed	Consecutive failures; 1	Works with the keep-alive interval and timeout to decide when the Session enters an error state
setOperationLimitOverrides	Operation counts; no overrides	Overrides the client's effective operation-limit values. It does not make the server accept larger requests or automatically partition arbitrary service calls.
setEndpointResolver	Resolver callback; absent on a bare config builder	Lets the client refresh the endpoint certificate during recovery. URL-based creation supplies a resolver, but config-based creation must configure one explicitly.

Client identity and trust defaults

These defaults matter as soon as a client leaves the loopback tutorials. A config builder defaults to anonymous identity. OpcUaClient.create(String) selects the first endpoint offering SecurityPolicy None and anonymous tokens, so use the selector overload to choose a secured endpoint.

Without a certificate group or an explicit certificate validator, the client does not validate server certificates. Selecting a secured policy alone does not establish trust. Supply an application identity or certificate group, plus a validator with the intended trust policy. See Connecting, Client security, and Recovery and limits.

Encoding and operation limits

Check these limits when a large request or response fails, or before you raise any of them. Both the client and server builders start from EncodingLimits.DEFAULT:

Encoding limit	Default
Maximum message size	2 MiB
Maximum chunk size	65,535 bytes
Maximum chunk count	64
Maximum recursion depth	128

Set these limits before startup with OpcUaClientConfigBuilder.setEncodingLimits(...) or OpcUaServerConfigBuilder.setEncodingLimits(...). EncodingLimits rejects a chunk size below 8,196 bytes. The client's setMaxResponseMessageSize(...) defaults to 0, which requests no response-size limit from the server, but local encoding limits still apply.

Transport limits, the server's advertised operation counts, and application memory limits are separate constraints. A request with a few large values can exceed the message limit even when its operation count fits.

A zero in a protocol field can mean no advertised limit, but zero does not mean the same thing for every builder property. Read Encodings and the setter's Javadoc before choosing a value. Partition large operations at application boundaries, preserve request and result order, and inspect both service and per-operation status.

Server and endpoint settings

These settings decide where a server listens, what it advertises, and how it authenticates users.

Endpoint addresses

EndpointConfig separates the local bind address from the advertised hostname:

EndpointConfig setting	Default
Bind address	localhost
Hostname	localhost
Bind port	12685

With these defaults an endpoint is local-only. The listener and the advertised URL use the same bindPort, and there is no separate advertised-port setting. A wildcard bind address is not a usable remote hostname, so advertise a name clients can resolve and reach. For secured endpoints, include the matching names in the certificate. See Deployment for NAT and port mapping.

Server application and authentication

OpcUaServerConfig connects the endpoints, certificate manager, identity validator, role mapper, access controller factory, encoding limits, and service limits. The builder starts with these defaults:

OpcUaServerConfigBuilder setting	Builder default	What to supply
Application URI	The placeholder server application uri not configured	A persistent application URI
Identity validator	An AnonymousIdentityValidator	The intended user-token validator
Certificate manager	None	A certificate manager

Authentication and authorization are configured separately. A user that the identity validator accepts is not automatically allowed to read, write, or call every Node. See Access control for effective user attributes and invalidation.

Server limits

OpcUaServerConfigLimits supplies the server's service limits. Counts are maxima unless stated otherwise, and the length fields are advertised server capabilities.

Limit or capability	Default
Sessions; Session timeout	100 Sessions; maximum 120,000 ms
Publishing interval	Minimum 10 ms; default 250 ms; maximum 8 hours
Nodes per Read or Write; MonitoredItems per call	10,000 each
Nodes per Browse, Method Call, or TranslateBrowsePathsToNodeIds	250 each
String, ByteString, and array maximum lengths	1,048,576 each; array length counts elements
Browse, Query, and History continuation points	250 for each kind
Password length	1,024 bytes

Two rows need care. The History continuation-point count and the four history-specific operation limits are advertised values, so the history provider must enforce consistent limits. See Historical access for the default dispatch checks and provider responsibilities. The Query continuation-point value does not imply Query support, because the default Query service is unsupported. See Capabilities and limitations.

When the defaults do not fit, pass your own OpcUaServerConfigLimits implementation to setLimits(...). Test both normal workload and limit rejection. Measure payload size, service latency, queues, and resource use first, instead of tuning from a target throughput number alone.

Subscriptions and sampling

These values govern how fast a server samples data and how subscription parameters are negotiated. Sampling acquires data, and publishing delivers notifications.

The client requests publishing, lifetime, keep-alive, sampling, and queue parameters, and the server revises them within its constraints. Read the revised parameters and per-item statuses before treating a subscription as ready. The server's publishing interval limits are in Server limits.

On a ManagedAddressSpace, SamplingManagerConfig controls interval grouping, minimum intervals, first-sample debounce, and read-access refresh policy. Start from SamplingManagerConfig.defaults():

SamplingManagerConfig component	Default	Effect
bucketMillis	25 ms	Supported sampling intervals are multiples of this size, and a requested interval is revised up to the next multiple. Zero disables bucketing.
minimumIntervalMillis	1 ms	The fastest interval, applied before bucketing. With the default 25 ms bucket and 1 ms minimum, the fastest supported sampling interval is 25 ms.
initialSampleDelayMillis	100 ms	Initial sampling waits this long for more new items
initialSampleMaxWindowMillis	500 ms	The maximum window for that wait
overrunWarningMultiple	3	A sampling cycle still running after this many intervals is logged
readAccessPolicy	ReadAccessPolicy.perCycle()	Read access refreshes every cycle

Custom device groups must still honor access decisions and lifecycle. See Subscriptions and Sampling for setup and migration.

Executors and lifetime

Read this when you supply your own threads or run several Milo components in one process.

Resource	Where to configure it	Default
Client executor, scheduled executor, event loop, and wheel timer	setExecutor, setScheduledExecutor, setEventLoop, and setWheelTimer on OpcTcpClientTransportConfigBuilder, reached through the configureTransport consumer of OpcUaClient.create(...)	The matching Stack shared resources
Server executor and scheduled executor	Server SDK builders	The shared executor and scheduled executor
Server event loop	OPC TCP server transport	The shared event loop

Client disconnect and server shutdown stop that client's or server's activity, but they leave the shared resources and any executors the application supplied running. The application sizes and shuts down the resources it supplies, and it must stop every user before closing a shared executor, event loop, or timer. Do not block transport or event-loop callbacks with device I/O or application waits.

Shut down clients, servers, namespace work, and application-owned resources in the order given in Deployment. Stack.releaseSharedResources() is a final, process-wide cleanup. Do not call it for one client while the process still hosts other Milo components.

Examples and reference

Your first server shows a complete local endpoint configuration, and the security guides add certificates and trust. When a configuration fails, record the selected endpoint, resolved application identity, requested and revised limits, and operation status before changing anything.

• Client builder and defaults
• Client configuration contracts
• Server configuration
• Encoding limits
• Endpoint defaults and URL construction
• Server builder defaults
• Server limit defaults
• Sampling defaults
• Client transport resources
• Server transport settings

Next steps

Settings describe what you ask Milo to do. To see which features Milo implements at this baseline and which parts your application must build, continue with Capabilities and limitations.

Related: Reference · Client connecting · Server configuration · Deployment