You see an error saying "Cannot create thread" with the following stack trace:
"Access ManagerSessionPoller" daemon prio=10 tid=0x0985e2e0 nid=0x37 in Object.wait() [0x10519000..0x10519a38] at java.lang.Object.wait(Native Method) - waiting on <0x2ad92c18> (a java.util.ArrayList) at java.lang.Object.wait(Object.java:474) at com.iplanet.Access Manager.util.ThreadPool.getTask (ThreadPool.java:125) - locked <0x2ad92c18> (a java.util.ArrayList) at com.iplanet.Access Manager.util.ThreadPool$ WorkerThread.run(ThreadPool.java:144)"
The problem is due to an insufficient amount of JVM heap size, or invalid Access Manager session threads are created out of control. This behavior is expected and not a deadlock at all.
Solution: To increase the JVM heap size, you can change the domain.xml manually or simply run Access Manager amtune-as8.
You may see in the error log stating that "search is not indexed". The Directory Server referential integrity plug-in is automatically enabled by the Access Manager. But no indexes exist for Access Manager's attributes such as iplanet-Access Manager-static-group-dn and iplanet-Access Manager-modifiable-by. Access Manager does not configure the arguments of the plug-in, but uses the default arguments (update interval=0). Every deletion causes an immediate integrity check, which consumes a lot of system resources when the search is not indexed.
Solution: Be sure the referential integrity plug-in is enabled and configured, and that the attributes to be maintained are indexed. Be sure the referential integrity is configured to be executed synchronously or with a delay. A delay will remove the thread shortage per application.
If you observe that one or more of the deleted entries are repeatedly added or deleted, over time these entries may trigger non-indexed searches to the database. This issue is addressed in later versions of Directory Server. Upgrade to Directory Server 5.2 Patch 5 or Directory Server 6.0.
Solution:First tune the JVM heap and GC (garbage collection) options for WebSphere Application Server. See Third-Party Web Containers for more information. Since JVM 1.4.2 or earlier is much slower than JVM 1.5.0 or later in throughput performance, make sure the JVM version used in the container is 1.4.2 or later when you use the CMS and NewParallelGC options. WebLogic 9.0 or later and WebSphere 6.0 or later use JDK 1.5.0 or later.
This occurs on Access Manager 7.0 or higher, even with sufficient JVM heap sizes.
Solution:Be sure that in addition to having sufficient JVM heap size, the CMS and NewParallel GC options are specified. Also be sure that -XX:-CMSParallelRemarkEnabled is included. See Third-Party Web Containers for more information.