What's New

The What's New topic lists new and revised features of TIBCO FTL® - Enterprise Edition version 7.0.1 compared to the previous version with reference to documentation.

7.0.1

OpenSSL 3.0.15 Support

TIBCO FTL® - Enterprise Edition now supports OpenSSL 3.0.15

Disaster Recovery for Routes

The disaster recovery feature may now be used with routed persistence clusters. For details, see Disaster Recovery for Routes in FTL Administration.

In addition, the "suspend" REST API command can be used with the disaster recovery feature for planned failback, regardless of whether routing is configured. For details, see POST cluster in FTL Administration.

I/O metrics for disk persistence

Added metrics to track low-level I/O activity for persistence services that are configured for disk persistence. The metrics are:

TIB_MONITORING_TYPE_DISK_WRITE_COUNT

TIB_MONITORING_TYPE_DISK_WRITE_BYTES

TIB_MONITORING_TYPE_DISK_READ_COUNT

TIB_MONITORING_TYPE_DISK_READ_BYTES

TIB_MONITORING_TYPE_DISK_FDATASYNC_COUNT

All metrics are available via the monitoring stream or prometheus endpoint.

Latency stats for persistence

Added metrics to measure round-trip latency from the persistence cluster leader to each replica, as well as the latency of disk writes in each persistence service.

For more details, see FTL Prometheus Metric Naming and Catalog of Metrics in FTL Administration.

Reduced IOPS Utilization

FTL disk persistence now generally uses fewer IOPS (e.g. in cloud environments). EMS using FTL stores also sees improvement in IOPS usage. The improvements are focused on medium-sized messages (a kilobyte or so).

Persistence service can now trace messages from select clients

To enable persistence message tracing, set the loglevel of the persistence services to "msg:debug", and set the loglevel of the client to "msg:debug". The persistence service only traces messages from clients with "msg:debug" set; messages from other clients are not traced.

For more details, see Message Tracing

7.0.0

Added a new monitoring metric, "no_match_msg_count"

Added a new monitoring metric, "no_match_msg_count". This metric tracks the number of messages sent to a persistence store that did not match any durables. Messages that do not match are dropped by the persistence service. In C API, the metric is TIB_MONITORING_TYPE_NO_MATCH_MSG_COUNT.

Added cumulative connection counts for FTL and eftl

Added a monitoring metric to track the total number of successful FTL client connections to an FTL server. In C API, the new metric is TIB_MONITORING_TYPE_FTL_CUMULATIVE_CONNECTION_COUNT.

OpenSSL 3.0.13 Support

TIBCO FTL® - Enterprise Edition now supports OpenSSL 3.0.13.

Retention and Replay of messages from a durable

You can configure a retention time on shared durable and standard durables with prefetch. When retention is enabled, acknowledged messages are retained until the retention time has elapsed.

When retention is enabled, users may rewind a durable using the user interface, REST API or the client API. Rewinding a durable allows new consumers to see a replay of messages that are published within the retention time.

For more information, see Retention Time

No Local Delivery

You are allowed to create no-local durable subscribers.

To create a no-local durable subscriber, pass the TIB_SUBSCRIBER_PROPERTY_BOOL_NOLOCAL_MESSAGE_DELIVERY property or API equivalent to the subscriber create call.

A no-local durable subscriber works like an ordinary subscriber, except that it does not receive messages published by the same TIBCO FTL client, even if the message matches the subscriber's interest.

A no-local durable subscriber may only be created on standard durables (with or without prefetch).

For more information see, No-Local Message Delivery.

Improved User Interface

The administrative GUI now has new options on the following pages:

• Realm Properties Details panel

• Durable Details panel

For more information see, Durable Details Panel and Realm Properties Details Panel.

Authentication mode

Built-In OAuth 2.0 Authentication

Clients may authenticate to TIBCO FTL server using a signed JWT token issued by an oauth server.

For details, see Using the built in OAuth 2.0 based authentication service.

If upgrading from 6.x, and oauth 2.0 authentication with TLS is desired, users should consider switching from FTL-generated certificates to user-defined certificates. This allows FTL to enforce token expirations.

For details, see Enabling TLS for FTL Server.

Prometheus Endpoints

TIBCO FTL server supports integration with Prometheus for application metrics monitoring. Prometheus is a monitoring tool that helps in analyzing the application metrics for flows and activities. Prometheus servers scrape data from the HTTP /metrics endpoint of the TIBCO FTL server. Prometheus integrates with Grafana, which provides better visual analytics.

New tibMap APIs to remove multiple keys

Added new client APIs that allow applications to remove several map keys in one API call. In C API, the new calls are tibMap_RemoveMultiple and tibMap_RemoveMultipleWithLock.

Improved TIBCO FTL disk persistence

The new FTL 7.0 database has an improved ability to expand or compact large databases without interrupting clients. The new database also offers the potential for improved performance in some scenarios, such as when using high-latency disks. When upgrading from the 6.x version, the old 6.x database will be automatically imported into FTL 7.0. For details, see Migration With Disk Persistence section.

Audit Log for Authentication

When the TIBCO FTL server loglevel is set to "auth:verbose", TIBCO FTL server will log authentication results for incoming connections from clients or other TIBCO FTL servers.