Persistent Publish-Subscribe Example

Persistence is the potential to store a message after sending it and before it is received so off line subscribers can consume it at a later time. Publishers and subscribers are completely decoupled. Subscribers can recover messages which may have gotten lost between the publisher and the subscriber due to network failure, resource issues along the delivery path, or any other failure. For details about persistence, see the FTL Concept guide, Persistence: Stores and Durables.

The sample programs from samples\bin\advanced are tibsendex (the publisher) and tibrecvex (the subscriber).

The following command line options are used for persistent message delivery:

  • -c option: Count of messages informing tibrecvex (subscriber) to exit after receiving n messages or tibsendex (publisher) to send n messages.

  • -d option: Durable name that specifies a durable name which is used to express interest in a particular message stream by a subscriber.

  • -e option: Endpoint to use that has been configured for persistence.

Perform these steps:

  1. Open two terminals. Make sure you have run the setup command and started the FTL server. See the Command Reference.

  2. In a terminal, start the tibrecvex sample application located in the /samples/bin/advanced directory, using the -c, -d, and -e options:

    • Linux and macOS:

      $.tibrecvex -a default -c 10 -d myDr -e persistent localhost:8080

    • Windows: 

      >tibrecvex -a default -c 10 -d myDr -e persistent localhost:8080

  1. In the other terminal, start the tibsendex sample application located in the /samples/bin/advanced directory using the -c and -e options.

    • Linux and macOS:

      $./tibsendex -c 20 -a default -e persistent localhost:8080

    • Windows: 

      >tibsendex -c 20 -a default -e persistent localhost:8080

Check Your Result

You should see the tibrecvex application receive the first 10 messages that are sent and then exit similar to the output below.

#

# tibrecvex

#

# TIBCO FTL Version <n.n> V<n>

#

Invoked as: tibrecvex -a default -c 10 -d myDr -e persistent localhost:8080

waiting for message(s)

received message 1

message:

type long: 1

type string: 'tibsend-persistent'

type opaque: size 6 data: 'opaque'

received message 2

message:

type long: 2

type string: 'tibsend-persistent'

type opaque: size 6 data: 'opaque'

received message 3

message:

type long: 3

type string: 'tibsend-persistent'

type opaque: size 6 data: 'opaque'

received message 4

message:

type long: 4

...

received message 8

message:

type long: 8

type string: 'tibsend-persistent'

type opaque: size 6 data: 'opaque'

received message 9

message:

type long: 9

type string: 'tibsend-persistent'

type opaque: size 6 data: 'opaque'

received message 10

message:

type long: 10

type string: 'tibsend-persist'

type opaque: size 6 data: 'opaque'

The tibsendex application messages contain three fields:

  • type long: Containing a monotonically increasing integer value

  • type string: Containing the fixed string tibsend-persistentendpoint

  • type opaque: Containing 6 bytes corresponding to the ASCII characters spelling out “opaque”

The tibsendex application sent all 20 messages.

#
# tibsendex
#
# TIBCO FTL Version <n.n>   V<n>
#
Invoked as: /tibsendex -c 20 -a default -e persistent localhost:8080 localhost:8080
sending message 1
sending message 2
sending message 3
sending message 4
sending message 5
sending message 6
sending message 7
sending message 8
sending message 9
sending message 10
sending message 11
sending message 12
sending message 13
sending message 14
sending message 15
sending message 16
sending message 17
sending message 18
sending message 19
sending message 20

Get the Next 10 Messages

The tibsendex application sent 20 messages. The 10 additional messages, numbered 11 through 20 are retained by an FTL store.

  1. Run the tibrecvex application again using the same command line.

  2. Check the result: You should receive the remaining 10 messages, even if the tibsendex application has completed sending all 20 messages and has exited.

If you see messages come in quickly at first and then slower, this receiver is getting previously sent messages quickly and, once those are delivered, subsequent messages are received in real-time based on the cadence of the publisher.

Failure and Restart

In a production scenario, persistence guards against system, network, or FTL server failures. Multiple FTL servers are run across multiple systems to provide redundancy for the persistence service so failures do not compromise your message delivery.

If you want to see how the persistence service ensures message delivery across subscriber failures and restarts:

  1. Increase the message count to a significantly higher number to give you time to stop tibrecvex before all of the messages have been delivered.

  2. Stop tibrecvex before all the messages are received.

  3. Restart it to receive the remaining messages.