TIBCO FTL® Persistence in 60 seconds

Table of Contents

• Getting Started with TIBCO FTL Persistence
• Start the TIBCO FTL realmserver
• Verify that the TIBCO FTL realmserver is running
• Configuring Persistence using TIBCO FTL REST API (using the attached configure_persistence.txt script)
• Starting the Persistence server
• Verify that the FTL Persistence server is running
• Starting the sender and receiver applications
• Additional details about the persistence configuration script

Got 1 minute?  Then you've got enough time to see how the TIBCO FTL^® persistence feature can guarantee the delivery of messages - even to subscribers that aren't even running at the time they are sent.

This tutorial demonstrates how to get started using TIBCO FTL persistence in less than 60 seconds.

This tutorial assumes that you have installed TIBCO FTL and installed the curl command line utility (available at https://curl.haxx.se/download.html). The tutorial assumes that you are running TIBCO FTL  on either Linux or macOS (the commands use the syntax as available in TIBCO FTL 5.2  for all command samples; if you are running a later version of TIBCO FTL, most of what you'll see here will be directly applicable as well and we'll call out any changes where appropriate).

Getting Started with TIBCO FTL Persistence

At this point, we'll assume that you've successfully installed TIBCO FTL and are at the command prompt, fired up and ready to to.

• Start the TIBCO FTL realmserver

  • Start the realmserver by invoking the 'tibrealmserver' script from the TIBCO FTL installation (typically installed at /opt/tibco/ftl/<version> with the common binaries located at /opt/tibco/ftl/<version>/bin on linux and macOS).  By default, the TIBCO FTL realmserver accepts client connections at localhost:8080.

    We're starting with an empty realm configuration which will be stored in the /tmp directory.  For ease of use, we recommend adding the appropriate bin directory to your PATH environment but if you choose to start the realmserver by using its full path, substitute the TIBCO FTL version in the path below with the version number for the package you installed.

    You'll see a number of informational messages giving the realmserver version and several status messages as the different components within the realmserver start up.

   $ /opt/tibco/ftl/5.2/bin/tibrealmserver --data /tmp

   

  You'll see a number of informational messages giving the realmserver version and several status messages as the different components within the realmserver start up.

• Verify that the TIBCO FTL realmserver is running

   $ curl http://localhost:8080/api/v1/server

   

  If the realmserver is running, you'll see a JSON-formatted response giving the realmserver version, some basic runtime statistics, and configuration settings - don't worry about the specific content; so long as you see it, you know the realmserver is up and running.

• Configuring Persistence using TIBCO FTL REST API (using the attached configure_persistence.txt script)

  • For ease of configuration, we're supplying a configuration script that will set all of the configuration options to enable persistence for our example programs.  The script will connect to the realmserver, set the appropriate configuration parameters and get things ready for the rest of the demo.

    This will all be configured to run on your local system.

   $ sh -f configure_persistence.txt

• Starting the Persistence server

  • Next, we'll start a single persistence server to support the actual message persistence.  For robustness, you would usually configure and start a set of these servers, but for now, a single server will do.

   $ /opt/tibco/ftl/5.2/bin/tibstore -n pserver -rs localhost:8080

• Verify that the FTL Persistence server is running

   $ curl http://localhost:8080/api/v1/persistence/cluster/servers/pserver

  You'll see a similar response to that seen when you queried the realmserver but from the persistence server instead - again, don't worry about the exact contents; if you see something, things are running.

• Starting the sender and receiver applications

  • Start the publishing application tibsendex and send 10 messages.  These messages will be held using the durable 'durable' by the persistence server.

   $ /opt/tibco/ftl/5.2/samples/bin/tibsendex -a testapp -e testep http://localhost:8080 --count 10 --delay 100

  The persistence server itself uses a logical component called a "store".  We can check that messages sent by tibsendex have persisted in the store called 'teststore'. Notice the output from the command below has a field named "message_count"; the value of this field indicates the number of messages stored in 'teststore' and should correspond to the number of messages sent since we've not yet started a recevier to consume the messages.

   $ curl http://localhost:8080/api/v1/persistence/cluster/stores/teststore  { "name": "teststore", "cluster": "cluster", "store_leader": "pserver", "durable_count": 1, "message_count": 10,  "message_size": 720 }

   

  Now, let's start the receiving application tibrecvex and consume the messages from the persistence store.

   $ /opt/tibco/ftl/5.2/samples/bin/tibrecvex -a testapp -e testep -d durable http://localhost:8080  --count 10

   

  We can verify that messages have been consumed by the receiving application by querying the persistence store once more. Notice the field "message_count"  which now has a value of 0 indicating that the store 'teststore' does not currently have any messages stored because they've all been consumed by the receiver application.

   &$ curl http://localhost:8080/api/v1/persistence/cluster/stores/teststore  {"name": "teststore", "cluster": "cluster", "store_leader": "pserver", "durable_count": 1, "message_count": 0, "message_size": 0 }

Done. TIBCO FTL's persistence capability provides message delivery guarantees even if the sender and receiver aren't up at the same time.  Your messages are persisted to ensure delivery in the event of application and network failures so that when a receiver starts, it will get the messages you intended for it to get. Of course, TIBCO FTL offers you complete control over how long messages are persisted, how many messages you want to persist, and a full set of other configuration settings; see the TIBCO FTL documentation for more details on the configuration options available.

If you are interested in some of the behind-the-scenes details, the next section goes over some of the contents of the configuration script itself.

Additional details about the persistence configuration script

The REST API commands used to configure persistence are shown here with a brief explanation of each of the commands.

  # Create a workspace before creating and deploying the configuration

 $ curl -v http://localhost:8080/api/v1/realm/workspace -X post

  # Create a persistence cluster named 'cluster'

 $ curl -v http://localhost:8080/api/v1/realm/persistence -d '{"name": "cluster"}'

  # Create a persistence server named 'pserver' within the persistence cluster 'cluster'

 $ curl -v http://localhost:8080/api/v1/realm/persistence/cluster/servers -d '{"name": "pserver"}'

  # Create a store named 'teststore' that will be a container for the durables within the cluster name 'cluster'

 $ curl -v http://localhost:8080/api/v1/realm/persistence/cluster/stores -d '{"name": "teststore"}'

  # Create a transport of type 'dtcp' that will be used by the application. NOTE: for certain persistence configurations transports are required to be set up for publishing and subscribing applications to talk to each other.

 $ curl -v http://localhost:8080/api/v1/realm/transports/testtransport -X put -d '{"name": "testtransport", "config": {"transport_type": "dtcp"}}'

  # Create a test application configuration that will be used by both the publishing app and the subscribing app, the app is configured with a store, cluster, transport, and dynamic durable template. Durable templates are basically a piece of configuration that dynamic durables can share (so that they don't have to specify this in the applications)

 $ curl -v http://localhost:8080/api/v1/realm/applications -d '{ "name": "testapp",  "endpoints": [{"name": "testep", "store": "teststore", "cluster": "cluster",  "transports": [{ "name": "testtransport", "receive": true,  "receive_inbox": true, "send": true,  "send_inbox": true }],"dynamic_durable": {"template": "default_standard"}}]}'

  # Finish the deployment

 $ curl -v http://localhost:8080/api/v1/realm/deployments -d '{"name": "deployment"}'

  # Delete the workspace.

 $ curl -v http://localhost:8080/api/v1/realm/workspace -X delete

configure_persistence.txt