Access Manger MUX Pool Exhausted error message
Originally Published: 2012-11-01
Article Number
Applies To
Issue
The aserver logs a very large volume of messages of this type:
sequence_number=33788,remote_client=aserver1,2012-08-24 04:00:03:886 CDT,messageID=15,result_code=0,result_action=MUX Event,result_reason=MUX Pool Exhausted
Resolution
This hotfix introduces two new configuration parameters that may be used to configure the frequency an threshold for mux log messages. The new mux log messages also indicate the queue length.
Here is an example message:
sequence_number=3,2012-10-12 15:18:22:812 IST,messageID=15,result_code=0,result_action=MUX Event,result_reason=MUX Pool Exhausted,mux_queue_length=52,mux_request_wait_count=430
You must add the following parameters to your aserver.conf file.
# Optional. This optional parameter specifies the wait time threshold
# for a request in the queue after which a MUX_POOL_EXHAUSTED error event
# is triggered for each request. The frequency at the will the MUX_POOL_EXHAUSTED
# message is logged depends on the value of cleartrust.aserver.mux.msg_log_threshold
#
# Allowed Values:
# Any positive integer that represents the number of milli seconds.
# A value of zero won't trigger the MUX_POOL_EXHAUSTED event.
#
# Default Value:
# 5000
#
#cleartrust.aserver.mux.request_wait_threshold=5000
# Optional. This optional parameter specifies the time
# interval between each MUX_POOL_EXHAUSTED error event.
#
# Allowed Values:
# Any positive integer that represents the number of milli seconds.
# A value of zero won't trigger the MUX_POOL_EXHAUSTED event.
#
# Default Value:
# 5000
#
#cleartrust.aserver.mux.msg_log_threshold=5000
If no logging is required change the values to 0. There can be some performance overhead when using mux pool logging. If you require warning about mux pool performance set the values high enough that log messages are only generated in exceptional circumstances.
To tune the mux pool increase the value of cleartrust.aserver.thread_pool_size setting until the mux_request_wait_count is acceptable.
For real time tuning of the mux pool it is more efficient to use SNMP.
Workaround
New functionality was added in SP4 that introduced a log message for mux pool tuning. This message is generated whenever an incoming request comes in and is not immediately passed to the mux pool thread. For many customers it is normal for this to occur. Items that are queued are serviced by the next free mux pool thread. What is more important is the length of the mux queue and the maximum time to clear events from the queue.
Related Articles
RSA Access Manger error message 'This stream has been closed'. Number of Views Unable to run the FIM backupConfig.cmd command in RSA Federated Identity Manger (FIM) 4.1 Number of Views Access Manger 6.1 aserver log shows 'Unable to send data to receiver' message Number of Views RSA Access Manger is unable to open new sockets Number of Views Error occured in RSA Federated Identity Manger (FIM) 4.1 'Unable to verify the signature value' error when processing asse… Number of Views
Trending Articles
RSA Authentication Manager Upgrade Process RSA Release Notes for RSA Authentication Manager 8.8 RSA RADIUS Server service failed to start in the RSA Authentication Manager 8.1 Operations Console Microsoft Entra ID External MFA - Relying Party Configuration Using OIDC - RSA Ready Implementation Guide RSA Release Notes: Cloud Access Service and RSA Authenticators
Don't see what you're looking for?
