Kbase P142359: How does AppServer broker shut down agents?
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  01/06/2010 |
|
Status: Verified
GOAL:
How does AppServer broker shut down agents?
GOAL:
What is AppServer broker shut down process?
GOAL:
Can an AppServer broker shut down busy agents?
GOAL:
What is preferred way to shut down a busy AppServer?
GOAL:
What are differences between stop and kill command on asbman?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
The shutdown command is the preferred way to stop an AppServer. It is the most orderly way to stop, and gives the application program the best opportunity to return itself to a stable state before terminating.
The behavior of the shutdown command depends on the operating mode of the AppServer. State-aware/reset AppServer wait for all client sessions to finish before shutting down; stateless/state-free AppServer proactively attempt to interrupt the current client sessions and shutdown.
The behavior of the shutdown command varies depending on the operating mode of the AppServer. Behavior falls into two general categories: (a) state-aware/state reset, and (b) stateless/state-free.
For state-aware/state-reset (i.e. client physically connected to agent):
When the shutdown command is issued to the broker, it sends a shutdown message to each running agent. If the agent is not connected to a client (i.e. is in AVAILABLE state), the agent will start the shutdown process immediately. This means that the agent must run the shutdown procedure before terminating. This could take some time, depending on what the shutdown procedure has to do.
If the agent IS currently connect to a client (i.e. is in CONNECTED state), the shutdown message is not processed until after the client disconnects and the agent becomes AVAILABLE. Once this occurs, then shutdown process is initiated. It is important to note that the broker makes no attempts to 'interrupt' the session between the client and agent.
Once all agents are terminated, the broker exits.
For stateless/state-free (i.e. clients physically connected to broker):
When the shutdown command is issued to the broker, it first terminates all current client connections. The way this is done depends on the state of the client connection:
o the broker closes all socket connections to client processes. This will be recognized by the client application as a network error.
o if a request is currently running on the connection, the broker interrupts the request. The steps taken for this vary depending on the state of the request (e.g. streaming the request into the agent, actually executing the request, or streaming the response back to the client). The server application may possibly report an abnormal termination to the request.
o once no request is currently running on the connection, the user is logically disconnected from the application. The broker fabricates a DISCONNECT request and queues it for an available agent to execute. The broker must wait for the DISCONNECT procedure to execute, and then responds to the broker.
o once all users are disconnected from the application, all client activity is complete, so all agents must be AVAILABLE. Once this occurs, the shutdown request is issued to each agent. The agent executes the shutdown procedure, and terminates.
o once all the agents terminate, the broker terminates.
The behavior of the kill command is quite different. When the broker receives the normal shutdown command or a kill command, the AppServer will attempt an orderly shutdown at first but when issued a kill command after a normal shutdown request or after an initial kill command, the broker terminates itself *immediately*; no attempt is made to perform any kind of orderly shutdown. This causes all client connections to be closed. The agent processes will detect that the broker process has terminated, and will exit immediately. No attempt is made to execute the DISCONNECT or SHUTDOWN procedures.
Sometimes the kill command can leave the agents is a 'bad' state, depending on what they're doing at the time the kill is initiated. If they happen to be blocked in a way that prevents them from recognizing that the broker has terminated, then they may be 'hung' and require manual intervention (i.e. OS kill on the process).