La console d'administration de Weblogic est beaucoup trop lente

Il s'avère que weblogic utilise un générateur de nombres aléatoires au démarrage. A cause d'un bug dans Java, il lit des bits aléatoires à partir de /dev/random . Il n'y a pratiquement aucun problème avec /dev/random sauf qu'il est extrêmement lent. Il faut parfois 10 minutes ou plus pour générer un seul numéro. Une solution simple existe - utiliser /dev/urandom à la place. Il n'est pas aussi bon que /dev/random mais au moins c'est instantané. Java en quelque sorte des cartes /dev/urandom pour /dev/random . C'est pourquoi les paramètres par défaut dans $JAVA_HOME/jre/lib/security/java.security sont inutiles, elles n'ont aucun sens.

La solution au problème est très simple - ajouter une chaîne export JAVA_OPTIONS="-Djava.security.egd=file:/dev/./urandom" a la /etc/bash.bashrc fichier. Utilisation de /dev/./urandom au lieu d'un simple /dev/urandom est un autre pirate. La JVM ne comprend pas la valeur de l'option autrement.

Soyez conscient de ce problème si vous essayez d'installer weblogic sous un système d'exploitation basé sur UNIX.

Il peut y avoir de multiples raisons pour cela, consultez le lien ci-dessous :

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

De plus, si vous commencez à faire face à des problèmes de façon aléatoire entre les deux, il est possible qu'un serveur géré soit sorti du cluster et que weblogic essaie de le connecter pour collecter des données jmx.

Dans ce cas, après avoir tué ce serveur géré, la console reviendra à un état normal.

Pour un débogage plus approfondi dans de tels scénarios, le journal des serveurs d'administration peut être vérifié pendant le ralentissement ainsi que les journaux de nodemanger.