Kbase P125523: Delay between the execution of CANCEL-REQUESTS() and the actual termination of a program on the AppS
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Unverified
SYMPTOM(s):
Delay in canceling an asynchronous RUN.
When the 4GL client calls the CANCEL-REQUESTS() method on the AppServer handle, it can take several seconds before the program on the AppServer is actually cancelled and stopped.
The code running on the AppServer may use the OS-COMMAND statement.
The code running on the AppServer may use the PAUSE statement.
The code running on the AppServer may block waiting for a record lock.
CAUSE:
This is a known limit.
When a client executes CANCEL-REQUESTS(), a network packet is sent to the AppServer agent. The AppServer agent process is single-threaded, and the CANCEL-REQUESTS packet will be seen by the agent only when the agent itself "takes its time" to check the queue of incoming network packets; usually that happens after the termination of one ABL statement, and before the start of the next one.
When an AppServer agent executes the PAUSE statement, or is waiting for a record lock to be released, or is executing the OS-COMMAND statement, it is busy executing those statements and will not check for incoming network packets.
The net result is that the agent will not know that a CANCEL-REQUESTS() was issued on the client side for a (potentially long) while.
FIX:
Avoid using statements that can block program execution for a long time, if it is deemed critical that an AppServer reacts to CANCEL-REQUESTS() in a timely fashion.
Also, please refer to Solution P98361 for considerations on using CANCEL-REQUESTS() in conjunction with a stateless AppServer.