Kbase P149672: State-free AppServer broker is using up all available client connections.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
19/01/2011 |
|
Status: Verified
SYMPTOM(s):
State-free AppServer broker is using up all available client connections.
ERROR: connection refused : maximum number of client connections has been reached. (8558)
The AppServer's broker.log file also includes many No Servers Available messages before the occurrence of the (8558) error.
ERROR: No servers available. (8089)
The client count in the AppServer broker.log file continues to increase until the default maximum (512) of maxClientInstance (as defined in the ubroker.properties file) is reached.
Running the promon utility and viewing the Lock Table (in the R&D, 1. Status Displays, 6. Lock Table screen) shows users holding limbo locks on records (released records that still have locks because the transaction has not ended yet) for an extended period of time.
promon also shows that there are users waiting to acquire locks on the records with limbo locks held by other users.
After changing the application code to limit transaction scope so that the record locks are released sooner, the "No servers available (8089)" errors have ceased and the client count of the AppServer broker has remained low.
FACT(s) (Environment):
The maxSrvrInstance parameter in the ubroker.properties file is set to 12 for this particular AppServer.
Linux
OpenEdge 10.1C03 64-bit Service Pack
CAUSE:
The exact cause is unknown at the time of this writing. Either the clients are not disconnecting properly or the broker is not disconnecting the clients when the maxSrvrInstance limit has been reached. The client count will continue to grow up to the maxClientInstance value as defined in the ubroker.properties.
FIX:
Either increase the maxSrvrInstance value to allow more servers to eliminate or minimize the possibility of reaching the maxSrvrInstance value, or change the application code to limit transaction scope so that records are not held for an extended period of time. Minimizing the transaction scope This will eliminate the need to spawn new servers that could potentially reach the maxSrvrInstance limit.