Recovery of a Disabled Process Restart versus Reopen the Realm

When the FTL server disables an application process, the application can recover in one of two ways: either create a new objects and resume operation, or exit and restart.

The appropriate course of action depends on business factors and program design factors:

  • Process restart cost. The program’s start sequence might be time-consuming, or use resources heavily. For example, a start sequence might load a large data set into process memory, or establish several database connections. Seek to avoid that restart cost by re-using the existing context and state.
  • Downtime cost. Business factors might require minimal interruption of an application process.
  • Parallel activities. An application might do some activities which do not require TIBCO FTL communication. It could be appropriate for those activities to continue non-stop operation while the program creates a new realm object. For example, a program could control machinery and also send sensor data to other applications. In this example the controller thread must not stop, even if sensor messages temporarily stop flowing.
  • Simplicity. Unless any of the preceding factors prohibit it, in many cases the simplest and fastest action is to exit and restart the program.
  • Fresh start. An application’s state could become stale while communications are suspended. Returning to a valid state might be more complicated or time-consuming than starting fresh.

Disabled Advisory

When the FTL server diables an application process, the process receives a CLIENT_DISABLED advisory. This advisory signals the need for recovery action.