Open topic with navigation

# 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 .

## Client - FTL Server 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 - Client Intervals

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

GUI Parameter | Description
--- | ---
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 waits 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.

## Statistics Settings

GUI Parameter | Description
--- | ---
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.
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.

Persistence Settings

GUI Parameter | Description
--- | ---
Unlimited 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. By default the Unlimited persistence retry toggle switch is enabled for Persistence operation calls to retry the interactions indefinitely. To disable, click the Unlimited persistence retry toggle switch to disable retry for persistence operations. This value only affects newly created subscribers, publishers, or map objects. Applications may override the default persistence retry duration when creating any of these object
Default to non-inline persistence sends | When enabled, by default publishers on endpoints with a persistence store will send messages non-inline. This offers the potential for increased throughput at the cost of higher latency. It also changes the semantics of the send call, since the application may return from the send call before the message is stored. This value only affects newly created publishers. Application code may override the default send policy when creating a publisher. For more information, see Publisher Mode
Prevent local message delivery | When enabled, newly created subscriptions enable no-local message delivery by default. The client’s application code may override. For more information, see No-Local Message Delivery in Development Guide.
Allow permissions | Disabled: When the Allow permissions toggle switch is disabled, the 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: When the Allow permissions toggle switch is 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 eFTL clusters (if used). See eFTL Clusters Grid.

General Settings

GUI Parameter | Description
--- | ---
Allow dynamic message formats | When the Allow dynamic message formats toggle switch is enabled, applications may use any formats, including dynamic formats. When the Allow dynamic message formats toggle switch is disabled, it restricts the formats available to applications. The only available formats are preload formats and built-in formats. For complete information, see Message Formats Administration
Default to no-inline peer-to-peer sends | When enabled, by default publishers on endpoints without any store will send messages non-inline. This offers the potential for increased throughput at the cost of higher latency. Applications may override this setting.
Warn about insecure transports between clients | When the Warn about insecure transports between clients toggle switch is enabled, then defining any transports that use nonsecure protocols triggers a validation warning. (This validation warning can trigger even if the FTL server does not enforce TLS and communications.)
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).

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO FTL® - Enterprise Edition

Copyright © 2009-2024. Cloud Software Group, Inc. All Rights Reserved.