This content has been marked as final. Show 6 replies
The information you provided isn't enough to troubleshoot your problems. You will need to enable debug logs to get more detailed error messages. My guess would be that you have run out of ldap connections, either no available network sockets or threads on the listeners which results in your user being unable to login. This often happens when your ldap server is not sufficiently tuned, but this is only a guess. You will need to enable the debug logs to see what the problem is.
Thanks for the answer.
We have a problem in the debug logs of nodes, because generates so much traffic and sometimes we had problems in our production enviroment... then we have not chance to discover the origin without this level of log?
If the origin of problem is ldap server then we could find some tracks in a kill -3, with for example a huge amount of threads of ldap connections or similar?
Thanks again, we will take a look in our ldap connectors, pools and servers.
We found a reason of this degradation, could be possible than, if one Policy Agent not answer, because the appserv -in this case weblogic- is saturated, could affected to the AM? I mean the appserv where the PA is installed depend of a finale system and this system is generating timeouts, and the appserv the is affected and the PA installed in it too, then all requests from the Access Manager have times of 30 40 50 seconds...
Can we have a solution configuring some specs in the AM or the solaris connections? like timeouts or time request?
I think the problem is this, because this PA installed attend the most request of the users
Anyway we thought than can fight to this tunning some specs in solaris like tcp_conn_req_max_q or tcp_conn_req_max_q0 and some timeouts like -Dsun.net.client.defaultConnectTimeout=10000 -Dsun.net.client.defaultReadTimeout=10000 but not seems enough because we are suffering this problems again.
If someone have an idea will be awesome, thanks!