Runtime States
Applications, features, hosts, nodes, and resource instances support different runtime states.
Object |
Runtime States |
---|---|
Application |
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 |
|
Host |
|
Node |
|
Resource Instance |
|
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.
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 is 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