Kbase P98361: Delay between the execution of CANCEL-REQUESTS() and the actual termination of a program on a statel
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/12/2010 |
|
Status: Verified
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.
Stateless AppServer
The problem does not occur on a state-reset AppServer.
The code running on the AppServer does not use the OS-COMMAND statement.
The code running on the AppServer does not use the PAUSE statement.
The code running on the AppServer does not block waiting for a record lock.
The code running on the AppServer does include ON STOP UNDO clauses in order to handle a STOP condition.
The code running on the AppServer does execute the PROCESS EVENT statement frequently.
FACT(s) (Environment):
OpenEdge 10.0x
OpenEdge 10.1A
OpenEdge 10.1B
All Supported Operating Systems
CAUSE:
Bug# OE00111621
CAUSE:
This is a known limit.
The delay comes from the fact that while the request is executing, the AppServer broker is not expecting to hear from the client, so it spends the majority of it's time waiting to get the response from the AppServer server. It only checks to see if the client has sent something every 3 seconds. This implementation is needed due to technical limitations in the Java language the broker is built in.
Once the client thread gets the STOP message, it forwards the message on to the server thread, which only checks it's input queue once every 3 seconds. This means that in the worst case scenario, it can take the AppServer broker a full 6 seconds to pass the STOP message on to the AppServer server, although, on average, it will take about 3 seconds.
Unfortunately, these timers are not configurable by the user.
FIX:
Upgrade to OpenEdge 10.1C or later.
Newer releases introduce a new property, "brkrSpinInterval" to the [UBROKER] group in the "ubroker.properties" property file. This property, specified in milliseconds, will allow setting the polling interval. The default value for this property is 3000 (i.e. 3 seconds) so the default behavior is unchanged. This property may not be set lower then 250 (ms).
Note that care must be taken when changing this value since smaller values will cause the broker to check its socket/queues more often. This may result in increased cpu usage.