eFTL Service Configuration Parameters

This topic presents the FTL server configuration parameters that apply to the eFTL service.

Example

This example configuration file illustrates two ways to use the eFTL section. First, it sets a parameter for the eFTL services in all servers. Second, it specifies a unique client name for the eFTL service on each of three servers. 

globals:

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

services:
    eftl:
        name: my_eftl_cluster
# ...

servers:

    ftl1:
        - realm: {}
        - eftl:
        client.label: eftl-svc-1

    ftl2:
        - realm: {}
        - eftl:
            client.label: eftl-svc-2

    ftl3:
        - realm: {}
        - eftl:
            client.label: eftl-svc-3
Parameter Arguments Description
name cluster_name Optional.

Cluster name.

An eFTL service belongs to exactly one eFTL cluster.

You may supply the name of the cluster to which this service belongs.

When absent, the default value is Cluster.
client.label label Optional.

When present, the eFTL service uses this string as its client label. You can use this string to distinguish among fault-tolerant eFTL services in the GUI.

Authentication and Authorization Service

Parameter Arguments Description
eftl.auth.url URL Optional.

When present, the eFTL service contacts an external authentication service at this URL.

eftl.auth.user user_name Optional.

When the authentication service URL uses the https:// protocol, the eFTL service identifies itself to the external authentication service using this user name credential.

eftl.auth.password password Optional.

When the authentication service URL uses the https:// protocol, the eFTL service identifies itself to the external authentication service using this password credential.

eftl.auth.trust path Optional.

When the authentication service URL uses the https:// protocol, use this parameter to specify the location of the external authentication service's public certificate file (in PEM format). The eFTL service uses the certificate to verify the identity of the external authentication service.

eftl.auth.retries max_retries Optional.

The number of retries for a failed request to the authentication service.

eftl.auth.timeout seconds Optional.

The number of seconds to wait for a response from the authentication service.

Security: EMS Server

Parameter Arguments Description
ems.path path Required for cooperation with an EMS server.

Supply the directory path where the EMS libraries are installed.

ssl.params path Required for secure connections to an EMS server.

The eFTL service reads parameters from this file, and uses them when connecting to a secure EMS server.

For details, see "SSL Parameters for EMS Connections" in TIBCO eFTL Administration.

Security: Legacy Clients

Parameter Arguments Description
server.cert path Required for backward compatibility with legacy clients that connect directly to the eFTL service.

The eFTL service reads a public TLS certificate from this file. It uses the certificate to authenticate itself to clients.

The certificate file must be in PEM format.

private.key path Required for backward compatibility with legacy clients that connect directly to the eFTL service.

The eFTL service reads an encrypted TLS private key from this file. It uses the key to authenticate itself to clients, and to encrypt TLS communication with clients.

The key file must be in PEM format.

private.key.password password Required if you specify private.key .

The eFTL service decrypts the private key using this password.

Messages

An eFTL service can automatically append user and client identification information to the messages that clients publish. See "Client Information Fields" in TIBCO eFTL Development.

Parameter Arguments Description
publish.client.id boolean Optional.

When present and true, the eFTL service appends the _client_id field to every message that any eFTL client publishes.

See "Client ID Field" in TIBCO eFTL Concepts.

publish.user boolean Optional.

When present and true, the eFTL service appends the _user field to every message that any eFTL client publishes.

See "User Field" in TIBCO eFTL Concepts.

Logging

Parameter Arguments Description
loglevel level Optional. eFTL services can inherit or override this value.

When present, the eFTL service logs at this level of detail. Supply one of these strings:

  • off
  • severe
  • warn
  • info
  • verbose
  • debug

    The output from debug and verbose can result in very large log files. This level of detail is generally not useful unless TIBCO staff specifically requests it.

    You may specify any of the standard log level strings (see “Tuning the Log Level” in TIBCO FTL Development). You can set a general log level, or custom log levels for different elements.

verbose Optional.

When present, the eFTL service produces verbose log output related to eFTL clients (but not related to other FTL elements, such as transports). It is equivalent to the loglevel value broker:verbose.

This level of tracing is appropriate only during client program development and testing.

logfile logfile_prefix Optional. eFTL services can inherit or override this value.

When present, the eFTL service logs to a rolling set of log files instead of the console. The logfile_prefix argument may denote a path. If so, then all of the directories in the path must already exist.

For more information about rotating log files, see “Log Output Targets” in TIBCO FTL Development.

When absent, the eFTL service sends log output to the console, and ignores the parameters max.log.size and max.log.size. .

max.log.size size Optional. eFTL services can inherit or override this value.

Limits the maximum size (in bytes) of log files. The value must be greater than 100 kilobytes, that is, 102400 bytes.

max.logs logs Optional. eFTL services can inherit or override this value.

Limits the maximum number of rolling log files.