Tuesday November 08, 2005

Directory Server 5.2 with less than 2Gb Entry Cache
Part two of my notes on the 2005Q4 release of the Java Enterprise System. This one is not so much of a workaround, more of an information piece. The Directory Server folks have been hard at work further increasing the performance of the Directory Server, and one of these improvements was a change in the way the entry cache is calculated. A side effect of this is that for rigs with an entry cache of less than 2Gbs you could encounter a performance degradation.

The workaround for this is very simple, just set the environment variable SUN_SUPPORT_SLAPD_DEFPOOL=true and restart your directory server. i.e for an ldap deployment called ds,

# cd /var/opt/mps/serverroot/slapd-ds
# SUN_SUPPORT_SLAPD_DEFPOOL=true; export SUN_SUPPORT_SLAPD_DEFPOOL
# ./start-slapd

Communications Express in Webserver Container Bug Work Arounds
The 2005Q4 release of the Java Enterprise System has come out, so I guess its time to share a few workarounds for some potential problems that you may see. First up is a product that we are working on with some of our colleagues in various parts of Sun, Communications Express. Two seperate gotcha type issues here, one of which is in the release notes, the other was hit at the end of the release cycle.

Firstly let us describe the communications express component (communications express is also referred to as UWC, which is what I will call it for the rest of this post) of the scenario that we have deployed. This deployment is relatively straight forward, with a Directory Server tier, an Access Manager tier deployed in an Application Server Web Container then Messaging Server and UWC on the same tier, with UWC deployed in a Webserver web container, and using the Access Manager SDK. Graphically this looks like.

The first issue is very straight forward, and is documented in the UWC release notes as bugid 6283991 (Java Exception on Web Server Startup after Configuration of Communications Express). This issue will manifest itself as a failure during the startup of your webserver with a stacktrace similar too

info: WEB0100: Loading web module in virtual server [ms.jestest.sun.com] at [/search]
failure: WebModule[/uwc]: WEB2680: Exception starting filter IdentitySSOAuthFilter
java.lang.NoClassDefFoundError: com/iplanet/am/sdk/AMException
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
        at java.lang.Class.getConstructor0(Class.java:2640)
        at java.lang.Class.newInstance0(Class.java:321)
        at java.lang.Class.newInstance(Class.java:303)

[ split accross lines for readability ]

/opt/SUNWam/lib:/opt/SUNWam/locale:/etc/opt/SUNWam/config:
/opt/SUNWam/lib/am_sdk.jar:/opt/SUNWam/lib/am_services.jar:
/opt/SUNWam/lib/am_logging.jar

info: CORE3282: stdout: AdminUtils: Could not initialize admin  info message: Got LDAPServiceException code=19
info: CORE3282: stdout: 10/04/2005 02:32:46:381 PM BST: Thread[Thread-1,5,main]
info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
warning: CORE3283: stderr: Failed to create debug directory
info: CORE3282: stdout: 10/04/2005 02:32:46:419 PM BST: Thread[Thread-1,5,main]
info: CORE3282: stdout: Intilize CryptoManager in JSSEncryption.java
info: CORE3282: stdout: 10/04/2005 02:32:46:427 PM BST: Thread[Thread-1,5,main]
info: CORE3282: stdout: ocspCheck value in JSSEncryption : false
info: CORE3282: stdout: 10/04/2005 02:32:46:574 PM BST: Thread[Thread-1,5,main]
info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
info: CORE3282: stdout: 10/04/2005 02:32:46:579 PM BST: Thread[Thread-1,5,main]
info: CORE3282: stdout: Crypt.static{}: Encryptor class= com.iplanet.services.util.JSSEncryption
warning: CORE3283: stderr: Exception in thread "Thread-1" java.lang.NullPointerException
warning: CORE3283: stderr:      at java.lang.String.(String.java:479)
warning: CORE3283: stderr:      at com.sun.identity.security.AdminPasswordAction.run(AdminPasswordAction.java:86)
warning: CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.server.SMSAuthModule.initialize(SMSAuthModule.java:131)
warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.LoginContext.login(LoginContext.java:122)
warning: CORE3283: stderr:      at com.sun.identity.authentication.internal.AuthLoginThread.run(AuthLoginThread.java:82)
info: CORE3282: stdout: 10/04/2005 02:32:46:587 PM BST: Thread[main,5,main]
info: CORE3282: stdout: AuthContext::getInformationRequired() returned from waiting for Callback array
info: CORE3282: stdout: 10/04/2005 02:32:46:587 PM BST: Thread[main,5,main]
info: CORE3282: stdout: AuthContext::getLoginStatus()
info: CORE3282: stdout: 10/04/2005 02:32:46:588 PM BST: Thread[main,5,main]
info: CORE3282: stdout: AuthContext::getInformationRequired() waiting for Callback array
info: CORE3282: stdout: 10/04/2005 02:32:46:588 PM BST: Thread[main,5,main]
info: CORE3282: stdout: AuthContext::getLoginStatus()