Remote server crashes with error 9874 or 893 - Client error 2659

Remote Server crashes with error 9874 or 893
Error 9874 only appears in the database log file.
All client sessions connected to a particular remote Server die.
Error message 2659 in log file of a connected Database or in a client log file or a WebSpeed server log.
May see vv_flush messages associated with clients from the same remote server.
 

Full stack trace from _mprosrv on Solaris reads:
 
uttrace()
utcore() 
drexit() 
msgout() 
msgn() 
strentd() 
strent() 
qrGetQuery() 
qrOpen() 
nsadoix() 
nsaloop() 
doserve() 
main() 
_start()

When there are too many queries left open on the remote server, the remote server crashes because there is no more memory available to handle additional requests and hit the strent limit.

This happens because queries on the client application are not closed properly on the client side.  

• Each query a client connected to a remote client server creates a structure in the memory of the remote client server.
• The structure takes up a bit of memory for each query.
• Any queries left behind by clients or not released by clients tie up the memory.  This will limit the number of future queries that can be handled by the Server. 
• The watchdog code will to try to clean up after abnormally terminated client sessions, but there may not be an immediate identification of when a remote client has terminated.  
• Application code can open a query without closing the query and therefore tie up the server memory as well and since this isn't an abnormal termination, the code introduced to release memory of terminated clients will do nothing to release these resources.

Data structures are larger on 64-bit versions, where it may not take as many open queries for this problem to occur in the newer versions of OpenEdge.

Each remote server keeps track of all its clients' queries (be it static or dynamic) in an area which cannot exceed 64 KB in 64 bit products and 32 KB for 32 bit products.  A very common cause for this issue is that dynamic queries or buffers referring to database tables are not cleaned up properly.

Analyze the application source code ensuring that all unused opened cursors are closed for each query opened by closing it as soon as the queries are no longer needed.  For additional debugging options, refer to Article:

• 00012302, How to detect ABL Memory Leaks with Dynamic Objects Logging 

The following simplified 4GL code illustrates the occurrence of the error 893. 

• In order to execute the code, connect to the sports database via remote connection (-S -H).
• To solve the problem remove the comments and re-run the code from another session 

 

DEF VAR hQuery AS HANDLE NO-UNDO.
DEF VAR hTable AS HANDLE NO-UNDO.
DEF VAR l-ok AS LOG NO-UNDO.

FOR EACH customer:

CREATE QUERY hQuery.
CREATE BUFFER hTable FOR TABLE "customer".

hQuery:SET-BUFFERS(hTable).
l-ok = hQuery:QUERY-PREPARE ('FOR EACH customer WHERE customer.custnum = 0').
hQuery:QUERY-OPEN().
hQuery:GET-FIRST(NO-LOCK).
/* DELETE OBJECT hQuery. */
/* DELETE OBJECT hTable. */
END.

 

Progress Article:

 What are common causes for error 893 and error 9874