Access Manger 6.1 aserver log shows 'Unable to send data to receiver' message
Originally Published: 2011-02-03
Last Modified: 2023-10-06
Article Number
000051585
Applies To
Access Manager 6.1
Issue
Access Manger 6.1 aserver log shows 'Unable to send data to receiver' message

The aserver shows a large number of messages of this type.  They appear to be associated requests from specific web agents.

sequence_number=23519,remote_client=aserver1,2011-01-11 15:35:57:401 GMT,messageID=-2,internal_error,description='Unable to send data to receiver.',details='java.io.IOException: Unable to send data to receiver.'

Cause
This message indicates that the agent failover mechanism occurred, and the agent failed over to an alternate aserver.  It is normal for some of these messages to occur in a production system, and the presence of this message by itself is not necessarily and indication of a problem.  This message is logged by the aserver when it attempts to contact the agent with a response and finds the agent socket is closed.  This may occur for the following reasons.
1) The aserver did not return a result within the agent timeout value
2) The agent was restarted or the web server was stopped or restarted and the aserver could not return the response.
3) A network error prevents the aserver from sending the response.
In situations where the aserver is slow, other log data should be used to determine the cause of the slowdown.  If the response is not in cache the aserver will have to contact the LDAP server to service the request. The most common cause for slow aserver response times is a slow LDAP server.  Tune the system to increase the records that are retained in cache to increase the response times of the aserver and reduce the load on the LDAP server.

Resolution
Ensure that the agents have a practical value for the cleartrust.agent.auth_server_timeout setting in the webagent.conf file.  The default value is 15 seconds and is adequate for most deployments.  Lower values may cause the agent to fail over to an alternate aserver when it should not.  This can affect performance in such situations where the agent contacts a secondary aserver.  In that instance, it will have to send the entire request again.
Notes
Note Access Manger servers 6.0.1 and earlier do not log the IP address of the client for this log message.  This ability will be included in later releases.  In order to determine what agent is responsible for the abandoned requests, you must look at other log entries in the log file.  Increase aserver log level to 30 or 40 and look for correlations between the unable to send data to receiver messages and other requests that do show the IP address.

Related Articles

Trending Articles

Don't see what you're looking for?