3. Experiment with adjusting the destination time-to-live

With the application deployed, you can use these steps to experiment with adjusting the destination time-to-live to hold messages even if a subscribing application is temporarily offline.

  1. Stop the backend application: 
    cf stop mql.fishalive.node.backend
  2. From the front-end application, click Submit Work. Note that without the backend running, no capitalized words appear on the web page.
  3. Restart the backend application: 
    cf start mql.fishalive.node.backend

    If you click Submit Work after it has restarted, you will once again see the capitalized words, but what happened to the words sent when the back end was stopped?

    They are lost because the default destination time-to-live is 0. When the client subscription ends when the backend stops, the destination is removed. Next, you’ll change this in the application code.

  4. Open the backend/app.js file in an editor and update the subOpts parameter for the subscription to include a ttl of 300000 milliseconds (5 minutes).
  5. Save the file and then republish the application with cf push
  6. After the applications are restarted, reload the page for the front-end application. Notice that if you use the Submit Work button from the front-end application, it works identically to how it did before the change.
  7. Stop the backend application. Wait one minute and then click Submit Work Wait one or two minutes, but not more and then restart the application. What happens?If you add the --recent option to the cf logs command, notice that only one application instance is usually able to clear all of the work before the second instance starts.
  8. Try waiting longer than 5 minutes before restarting the backend or sending a message 4 minutes after stopping the backend. Then, wait 2 minutes after that to restart the backend. Do you think you will get different results? Have some fun!