Weblogic administration console way too slow

Question

I've installed weblogic 10.3.3, configured simple domain with default configuration. And after starting weblogic I cannot use it via admin console because it is starting too slow (~10 mins). It seems that admin console application is being deployed incorrectly. Even when I enable 'staging' mode in AdminConsole deployment options, it does not help. Does anybody have a solution for this problem? It really bugs me out.

---

Configuration properties:

Server: Dell PowerEdge r410 server (Six-core Intel® Xeon® x64 CPU, 8GB RAM)

OS: Ubuntu Maverick 10.10 x86_64

Weblogic: 10.3.3 x64 (used wls1033_generic.jar file for installation)

Java:: 1.6.0_17_i586 (tried with different jdk's including x64, but it does not work either)

Answer 1

Turns out weblogic uses random number generator during startup. Because of the bug in java it reads random bits from /dev/random. There are almost no problems with /dev/random except that it is extremely slow. It takes sometimes 10 minutes or more to generate one number. Simple solution exists – using /dev/urandom instead. It is not that good as /dev/random, but at least it is instant. Java somehow maps /dev/urandom file to /dev/random. That’s why default settings in $JAVA_HOME/jre/lib/security/java.security are useless, they just do not make any sense.

Problem fix is very simple – adding string export JAVA_OPTIONS="-Djava.security.egd=file:/dev/./urandom" to the /etc/bash.bashrc file. Usage of /dev/./urandom instead of simple /dev/urandom is another hack. JVM does not understand the option value otherwise.

Be aware of this problem if you try to setup weblogic under UNIX-based OS.

Answer 2

There might be multiple reasons for this check below link:

https://blogs.oracle.com/LuzMestre/entry/why_does_my_weblogic_server

Also if you are started facing in randomly in between then there might be possibility that any one manged server has got out of cluster and weblogic is trying to connect it for gathering jmx data.

In that case after killing that managed server console will come to normal state.

For further debugging in such scenarios admin servers log can be checked during slow up along with nodemanger logs.