Open topic with navigation

# Realm Service Configuration Parameters

This topic presents the FTL server configuration parameters that apply to the realm service. Also see: Realm Service.

## Example

This example configuration file illustrates the use of realm services configuration.

    globals:  # These values apply to all servers.

      core.servers: # The set of core servers and their locations.
        ftl1: host1:8585
        ftl2: host2:8585
        ftl3: host3:8585

      # All servers inherit this value.
      auth.url: file:/myhome/ftlserver/secure/myauthfile.txt

    servers:
      ftl1:
        - ftlserver.properties:
            logfile: TIBCO_HOME/logging/ftl2/logs/ftl1.log
        - realm:
            loglevel: debug
        - persistence:
            name: p1
        - bridge:
            names:
              - bridgeA
              - bridgeB

      ftl2:
        - ftlserver.properties:
            logfile: TIBCO_HOME/logging/ftl2/logs/ftl2.log
        - persistence:
            name: p2
        - bridge:
            names:
              - bridgeA
              - bridgeB
        - eftl:
            loglevel: debug

      ftl3:
        - ftlserver.properties:
            logfile: TIBCO_HOME/logging/ftl3/logs/ftl3.log
        - persistence:
            name: p3
        - eftl:
            loglevel: debug

## Logging

Parameter | Arguments | Description
--- | --- | ---
loglevel | <level> | When present, the realm service logs protocol communication at this level of detail. You may specify any of the standard log level strings. See “Tuning the Log Level” and its sub-topics in TIBCO FTL Development. You can set a general log level, or custom log levels for different elements. When this parameter is absent, the default level is info.

## Initial Configuration

Parameter | Arguments | Description
--- | --- | ---
initial.realm. config | <filepath/filename> | During the initial deployment, if this parameter is set, the contents of this file are deployed. Otherwise, the default realm configuration asset is deployed. This parameter is not used on subsequent runs of the FTL server. Note that clients are unable to connect to the realm server until after the initial deployment has successfully completed. The FTL server logs any validation errors regarding the contents of the initial deployment file, and deployment will fail.
`default.cluster. disk.swap` | boolean | Enable (`true`) or disable (`false`) message swapping for the default cluster. When message swapping is enabled, the server can swap messages from process memory to disk. Swapping allows the server to free process memory for more incoming messages, and to process message volume in excess of memory limit. When the server swaps a message to disk, a small record of the swapped message remains in memory. This can be enabled with or without disk persistence. If enabled without disk persistence, data is written to a temporary swap file. This option can apply to replicated or non-replicated stores. Note: When using message swapping, if all FTL servers in the cluster are restarted simultaneously, messages in the store prior to the restart are not retrievable after the restart unless disk persistence is also enabled.
`default.cluster. disk.persistence` | disk mode | Select the disk persistence mode. `none`: Disable disk persistence. `sync`: The client returns from a send-message call after the message has been written to a majority of disks. This mode generally provides consistent data and robustness, but at the cost of increased latency and lower throughput. If the cluster restarts, no data is lost; performance is subject to disk performance. `async`: The client may return from a send-message call before the message has been written to disk by majority of the FTL servers. This mode generally provides less latency and more throughput, but messages could be lost if a majority of servers restart shortly after the API call.
default.cluster. disk.nocompact | disk mode | Auto compaction is disabled by default in the initial realm configuration for the default cluster.

## TLS Security

Parameter | Arguments | Description
--- | --- | ---
tls.san | SAN spec | Optional. Add a SAN (Subject Alternative Name) to the certificate generated by the FTL server. When no custom certificate is configured, this certificate is presented to: Secure eFTL clients (WSS) HTTPS clients of the eFTL REST API HTTPS clients of the FTL realm UI or realm REST API This parameter can be used to customize the certificate in cases where the clients above connect to a hostname unknown to FTL server (for example, the hostname of a load balancer). Example: `IP:1.2.3.4,DNS:myhost.com`

## Affiliated FTL Servers

Parameter | Arguments | Description
`satellite.heartbeat` | seconds | Communication with satellite realm services. The default is 1 second.
`satellite.timeout` | seconds | Communication with satellite realm services. The default is 3 seconds. An FTL server waits for this timeout interval before repeating its connection request to an affiliated FTL server.
`backup.heartbeat` | seconds | Communication with disaster recovery realm services. The default is 1 second.
`backup.timeout` | seconds | Communication with disaster recovery realm services. The default is 3 second. An FTL server determines that an affiliate is unavailable when the affiliate's heartbeat signal is silent for this timeout interval.

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.