Kbase P11976: Client exits ungracefully when connected to AppServer
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Unverified
GOAL:
What if client dies during an AppServer connection
GOAL:
What should happen to the AppServer process on an ungraceful logoff of the client.
GOAL:
Client exits ungracefully when connected to AppServer
FIX:
Under normal circumstances and GRACEFUL disconnects from the client machine, for a correctly written program, we execute the code:
ret=hAppSrv:DISCONNECT().
DELETE OBJECT hAppSrv.
This code allows the AppServer process to disconnect as it has been informed by the application that the client is disconnecting. Since there is a one-to-one ratio between the client and AppServer, the AppServer processes' sole purpose is to service that client, hence the disconnection when the client goes away.
TCP or socket KeepAlive is a mechanism with TCP/IP that allows a process to time out and be disconnected if there is no activity for a set period of time or if a connection is dropped. How this works is that the TCP daemon runs to monitor activity on a process. If there is no activity on the process for the time period defined by socket KeepAlive then the TCP stack sends an empty probe packet to the process to check and see if it is still out there.
If there is no response to the probe packet for the time period defined by the socket KeepAlive setting then it notifies the parent process that the child is dead and sends a connection reset to the parent which in turn shuts itself down. Once this TCP connection is lost it cannot be reestablished.
How this all affects AppServer is somewhat complex but plausible.
Since connecting to the AppServer instance is a network connection, we are relying on a client disconnection to send a hangup signal to Progress, in which case we have a GRACEFUL logoff. When this occurs, the disconnect code mentioned earlier executes and the AppServer is able to shut itself down when the signal is sent and the code is executed. If the signal does not get sent for a reason such as a user powering off their PC, or closing a window on a terminal emulator, then the shutdown code does not get executed and the AppServer process stays active as it is not aware of the disconnected client. If TCP KeepAlive is functioning as explained earlier, then it should cause the AppServer process to shut itself down (on version 8) or to return to the 'AVAILABLE' state, on later versions.
One of the potentially confusing parts of this is the physical location of the AppServer with respect to the client and the database. Regardless of the location of the AppServer, whether local to the database or the client machine, if TCP is functioning properly then KeepAlive should take care of any AppServer process left out there by a dead client that did not send a signal.
This has been tested on several different platforms with the AppServer residing both locally to the client and then local to the database and has performed as expected in all situations. If the AppServer process is not shutting itself down then speak with your Operating System vendor to verify the TCP KeepAlive is functioning correctly.
For early version of V9 AppServer, the KeepAlive option is not enabled by default for client-side sockets. That means the KeepAlive will not work for Stateless AppServer, and you may see server process in the CONNECTED / LOCKED state when querying the broker due to a client disconnected when the TCP KeepAlive timed out.
This KeepAlive option is implemented in the latest patches for 9.1C and in 9.1D. The server process will release the Application Server process after a connection failure based on the KeepAlive setting, and the server process will be shown as AVAILABLE.