Runtime States

Applications, features, hosts, nodes, and resource instances support different runtime states.

Runtime States

Object 		Runtime States
Application
  • Not Deployed - before an application is deployed.
  • Deployed - when the application is deployed.
  • Partially Undeployed - while an application is being undeployed.
  • Partially Running - the application is deployed to more than one node but the application is not running on all those nodes.
  • Starting
  • Start Failed - click the Action History link in the Administrator to get more information.
  • Running
  • Stopped - after the application has been started and stopped.
  • Stopping
  • Partially Stopped - The stop command is executed for an application but not all components and bindings of the application are stopped on all nodes.
  • Waiting for Dependencies - either a resource instance or application that this application depends upon is not running. Once all dependencies are running, the components which are waiting will automatically be started.
  • Preparing for Undeploy - the application is waiting for process instances and work items to be completed.
    Note: This is a normal state when undeploying an application and there are process instances or work items that are open. The application can remain in this state for a very long time, since completing the open work items involves manual intervention. When the work items are completed, the application will be automatically undeployed.
  • Interrupted Preparing for Undeploy - indicates the application that was preparing for undeploy was either stopped, or its dependency taken away.
    Note: An application may depend on other application processes. If any of the dependent applications are stopped or undeployed, it takes away a dependency for the main application. In such a situation, the main application will go into a state of Interrupted Preparing for Undeploy and will no longer progress work or process instances. To recover from this state, you can either start the application or bring back the dependencies by starting the processes or deploying the dependant applications.
  • Partially Ready for Undeploy - some components have completed processing and have been marked as ready for undeploy, but other components in the application have yet to complete processing.
  • Unknown
  • Lost contact - when a host has lost contact with the Administrator server.
Note: The runtime state is a roll-up value for all the application's components and bindings. Partial states mean that some of an application's components and bindings are in a different state than others.
Feature
  • Marked for Install - after a feature has been added to a node and before the change has been applied to runtime.
  • Marked for Uninstall - after a feature is removed and before the change is applied to runtime.
  • Installed - after a feature has been applied to runtime.
Host
  • Initializing
  • Initializing Failed - click the Action History link to get more information.
  • Initialized
  • Lost Contact - when the host has lost contact with the Administrator server.
  • Starting
  • Starting Failed - click the Action History link to get more information.
  • Running
  • Stopping
  • Stopped - when the host is explicitly stopped and has completed the shutdown process.
  • Unknown
Node
  • Not Installed - after a node has been created and before it has been installed
  • Not Running - after a node has been installed or when it was detected that the node ended without being stopped by the host. This applies when the process is detected as stopped.
  • Stopping - Stopping a node is expected to be a quick activity. If the node is stuck at Stopping for more than a few minutes, checking the logs may indicate the problem.
  • Stopped - the node was explicitly stopped. This is a normal and expected condition.
  • Starting - Starting a node is expected to be a quick activity. If the node is stuck at Starting for more than a few minutes, checking the logs may indicate the problem.
  • Start Failed - The host was not able to start the node process. Possible causes are that the node_classpath.tra file contains errors, the JRE libraries are not found, or the OS is unable spawn additional processes. After this state ,the node is disabled and must be manually enabled.
  • Running
  • Lost contact - When a host has lost contact with the Administrator server.
Resource Instance
  • Not Installed - after a resource instance has been added to a node and before it has been installed
  • Running - after a resource instance has been installed and the node on which it has been installed is Running
  • Uninstalled - the resource instance is uninstalled
  • Stopped - when a host has lost contact with the Administrator server or when the node where the resource instance is installed is in Stopped state.
  • STAND_BY - the resource instance is registered to the Node but not yet Started. For more details, see the sub-section "STAND_BY State" later in this section.

If the Runtime State column of applications is Lost Contact or Unknown, the connection to the Enterprise Message Service server acting as the notification server and Messaging Bus has been lost.

Note: After you upgrade an Administrator server, the runtime state of applications running on a node managed by a TIBCO Host instance that has not been upgraded is Partially Running.

STAND_BY State

An HTTP Connector stops listening to client connections when there are no service endpoints or applications available to serve the requests. In other words, if all the applications using an HTTP Connector are stopped (or undeployed), the HTTP Connector also stops. For this case, an external HTTP load balancer can detect the unavailability of the endpoint, mark it as offline, and stop routing requests to it. When applications are started, the HTTP connector automatically starts listening on its port, such that the external HTTP load balancer can detect the endpoint as online and start routing requests to it. The 'Stand By' state for HTTP Connectors represents the stopped state.

Upon installation, an HTTP Connector appears in the 'Stand By' state. When the first Application using the HTTP Connector starts up, the HTTP Connector changes the state to the 'Running' state. When the last Application using the HTTP Connector is stopped, the HTTP Connector goes back to the 'Stand By' state.

  • Behavior for HTTP 404 when an endpoint URI is invalid: When two or more applications share an HTTP Connector, and even if one of the applications is running, the HTTP Connector appears in the 'Running' state. However, some of the other applications may be in the 'Stopped' state, and client requests targeted for those applications result in the HTTP error code 404 (Not Found).

    Earlier, the response body accompanying the 404 code was in the HTML format and caused the parsing errors for SOAP clients that were expecting a SOAP response. With this release, depending on the request type sent by the client, either a valid SOAP fault is generated, or the HTML content is returned with an error message. For example, a SOAP client trying to invoke a service at endpoint '/myservice' receives a SOAP fault along with HTTP 404 status code when the URI '/myservice' is not available. However, when a browser client tries to access '/myservice', an HTML body is returned indicating that the URI was not found.

  • Behavior on Node restart: When a runtime Node is restarted, the HTTP Connectors are started first, and then each Application starts one-by-one. With the new behavior, the HTTP Connector goes into the 'Stand By' state and as the first Application starts, the HTTP Connector changes the state to the 'Running' state. While applications are still starting up, there will be a small time interval when client requests receive the 404 error as previously explained.
  • Reverting to the old behavior: While the new behavior should work better in most instances, there may be a case where the old behavior is desired. You can restore the old behavior (that is, no 'Stand By' state) by adding the following line to the runtime node's TRA file and restarting the node: 
    java.property.com.tibco.jetty.httpconnector.eager.start=true