Realm Properties Details Panel

The Realm Properties details panel presents the global values of realm properties. In edit mode, you can modify the property values. Click the Realm Properties icon .

Intervals

Several intervals affect the operation of the FTL server and its interaction with clients.

GUI Parameter Description
Client to FTL Server Heartbeat

The interval at which a client application sends a heartbeat to the FTL server process when no data flow is present (which is also necessary to carry monitoring data). The default is 60 seconds.

Zero is a special value, instructing the clients not to send heartbeats.

Client to FTL Server Timeout The amount of time a client waits for a response to the heartbeat sent before closing the existing connection to the FTL Server and initiating a client reconnection. The default is 180 seconds.
FTL Server to Client Heartbeat The FTL server sends heartbeats to its clients at this interval, in seconds. The default is 60 seconds.

Zero is a special value, instructing the FTL server not to send heartbeats.

FTL Server to Client Timeout

The amount of time a FTL server will wait for a response to the heartbeat from the client application process. If no response is seen, the FTL server closes the existing connection. The Default is 3600 seconds (1 hour) to allow the FTL server to maintain connections with transient clients as needed. The server can miss at most 60 heartbeats before triggering the client to close the connection.

When a client does not receive server heartbeats for this interval, the client actively attempts to reconnect to a server. If the server is part of a fault-tolerant cluster, the client can failover to another core server in the local cluster.

The FTL Server uses this timeout to reap connections that are no longer valid.

Client Sampling Interval Clients take samples of their operating metrics at this interval, in seconds.

Zero is a special value, instructing all clients to disable the monitoring feature.

See Catalog of Metrics and Log Service.

Dynamic Message Formats

Message formats can affect network bandwidth usage.

GUI Parameter Description
Dynamic Message Formats Do not allow: Restrict the formats available to applications.

Allow: When enabled, the only available formats are preload formats and built-in formats. For complete information, see Message Formats Administration.

Persistence Retry

Persistence operations can be set.

GUI Parameter Description
Persistence Retry Persistent publisher operations, subscriber operations, and map operations require access to the persistence service. When they cannot access the persistence service (usually because of network failure or quorum unavailability), they can automatically retry the interaction.
  • Unlimited The default behavior. Persistence operation calls retry the interaction indefinitely. Calls return only upon success.
  • None Persistence operation calls that cannot access the persistence service raise an exception.

Properties of individual publishers, subscribers, and map objects within application programs supersede this global setting.

Note: In Release 6.0.0 the default behavior changed to Unlimited. In earlier releases the default behavior was None.

Collect Subscription Statistics

You can control whether clients and services collect fine-grained monitoring metrics about subscriptions and message substreams. Note that these metrics produce a large volume of monitoring data.

GUI Parameter Description
Collect Subscription Statistics Enabled: When enabled, clients gather monitoring metrics about subscriptions and message substreams, and send them to the FTL server.

Disabled: When disabled, clients do not gather these metrics.

Secure Communications

The FTL server enforces TLS security in its communications with clients.

If the FTL server does not use secure communications, a warning appears at the top of this section.

GUI Parameter Description
Warn about insecure transports between clients Warn: When enabled, defining any transports that use non-secure protocols triggers a validation warning.

(This validation warning can trigger even if the FTL server does not enforce TLS communications.)

Do not warn: There is no validation warning when defining transports that use non-secure protocols.

Service Connection Policy

The service connection policy affects client connections to services that are configured to use the auto transport. The most common example is the client transport of the default persistence service. If the FTL client can connect directly to each FTL server, Force Direct is appropriate. If the FTL client cannot connect directly to each FTL server, then Default or Routed is appropriate.

GUI Parameter Description
Service Connection Policy

Set the service connection route.

  • Default: The FTL client attempts to determine the best connection path to the service automatically.

  • Force Direct: The FTL client connects directly to the FTL server hosting the service. If no direct path exists, the connection fails. This option is suitable for situations where consistent latency or a consistent network path is desired. Force Direct can reduce the cost and latency associated with an indirect path from client to server, provided that the FTL client can connect directly to each FTL server.

  • Routed: Routed causes the FTL client to initiate all connections using the URL(s) provided in the realm connect call. This is appropriate when it is known that the FTL client is unable to connect directly to each FTL server (for example, the FTL servers are behind a load balancer).

Permissions

GUI Parameter Description
Permissions

When both TLS and authentication are enabled, the Permissions item is displayed. See Permissions.

Disabled: Permissions are not enabled for the FTL realm. If authorization is required for any eFTL channels, then the legacy method may be used:

  • Set Publish Group and Subscribe Group to the appropriate values for each eFTL channel on the channel details page.

  • Select the Authentication checkbox on the eFTL clusters grid. See eFTL Clusters Grid.

Enabled: Permissions are enabled for the FTL realm. Access to persistence clusters, persistence stores, and eFTL channels can be controlled by assigning permissions on the Users and Roles grids. Ensure that all persistence transports are secure. Ensure that the Authentication checkbox is checked for all eFTL clusters (if used). See eFTL Clusters Grid.