OpenDJ: Replication Setup Error Message

Today, I hit into some issues with OpenOSSO multi-servers setup. I am suspecting there's something not correct with the OpenDS configuration in a multi-servers deployment. Nothing concrete yet, am still investingating.

In order to provide some facts, I think setting 2 instances of OpenDJ in MMR mode would be good. At least, I have something to compare with.

So, the installation of OpenDJ was a breeze. (Do I re-broadcast so many times on this fact? :>)


Setting up replication is not hard if you have the following command line as a template. (No GUI yet to set up replication.)

[opendj@think bin]$ ./dsreplication enable --host1 think.sg.forgerock --port1 8888 --bindDN1 "cn=directory manager" --bindPassword1 password --replicationPort1 8989 --host2 think.sg.forgerock --port2 7888 --bindDN2 "cn=directory manager" --bindPassword2 password --replicationPort2 8989 --adminUID admin --adminPassword password --baseDN "dc=sg,dc=forgerock" -X -n


Establishing connections ..... Done.


You have provided the same replication port (8989) for two servers located on the same machine (think.sg.forgerock).


So, am I done or not done? Initially, I thought I'm done. But ... actually, it's not done.

Wouldn't the following be better?

ERROR: You have provided the same replication port (8989) for two servers located on the same machine (think.sg.forgerock).


.

java.lang.OutOfMemoryError: unable to create new native thread

I have been driven crazy for the past 2 weeks performing load tests for the Single Sign-On infrastructure in a local ministry.

Today, one of the customized application threw the following error:

java.lang.OutOfMemoryError: unable to create new native thread

While searching for a solution, I came across the following diagram. I think it's good to share as it's very clear in illustrating how to tune a 32-bit JVM. 

I had set the request processing thread (thread-count) to a high number of 500. (Ya! I was crazy to do that) At the same time, I set the Xmx and Xms to 2GB.

So the math was rather bad (if you can follow the diagram above). Ha!

In the end, we settled for Xmx and Xms to 512MB with thread-count being 200. The application flies!


.

Goodbye, Sun Messaging Server!

 Last Saturday, we finally decommissioned the Sun Messaging Server in our data center.

As everyone knows, Sun's software used to be free to use, even in production. Customers only need to pay if they require support. Well, that was yesterday and history. :)

Salute to Sun Messaging Server!

SSL handshake

There has been a lot of discussions on how to configure SSL-enabled OpenAM servers to communicate with one another via self-signed certificates.

Actually, honestly speaking, it's not an OpenAM issue. It's a JDK key-store issue. One needs to understand how SSL works. As mentioned in my blog some times back, I found this link a good start.

These days, I am using SSLPoke pretty often. This is the most wonderful tool to have. I'll make sure SSLPoke pass before I continue to configure the 2nd and subsequent OpenAM server.

Or you can set the following JVM-option:
"-Djavax.net.debug=SSL,handshake,trustmanager"

This will show why SSL handshake fails.


.