Console de administração do Weblogic muito lento

1

Instalei o weblogic 10.3.3, domínio simples configurado com configuração padrão. E depois de iniciar o weblogic eu não posso usá-lo via console de administração porque ele está começando muito lento (~ 10 minutos). Parece que o aplicativo do console de administração está sendo implantado incorretamente. Mesmo quando eu habilito o modo 'staging' nas opções de implantação do AdminConsole, isso não ajuda. Alguém tem uma solução para esse problema? Isso realmente me incomoda.

Propriedades de configuração:

Servidor: Servidor Dell PowerEdge r410 (CPU Intel® Xeon® x64 de seis núcleos, 8 GB de RAM)

SO: Ubuntu Maverick 10.10 x86_64

Weblogic: 10.3.3 x64 (usado o arquivo wls1033_generic.jar para instalação)

Java: : 1.6.0_17_i586 (tentei com jdk's diferentes incluindo x64, mas também não funciona)

    
por altern 16.04.2011 / 12:31

2 respostas

2

Acontece que o weblogic usa o gerador de números aleatórios durante a inicialização. Por causa do bug no java, ele lê bits aleatórios de /dev/random . Quase não há problemas com /dev/random , exceto que é extremamente lento. Leva, às vezes, 10 minutos ou mais para gerar um número. Existe uma solução simples - usando /dev/urandom . Não é tão bom quanto /dev/random , mas pelo menos é instantâneo. De alguma forma, o Java mapeia /dev/urandom file para /dev/random . É por isso que as configurações padrão em $JAVA_HOME/jre/lib/security/java.security são inúteis, elas simplesmente não fazem sentido.

A correção do problema é muito simples - adicionando a string export JAVA_OPTIONS="-Djava.security.egd=file:/dev/./urandom" ao arquivo /etc/bash.bashrc . O uso de /dev/./urandom em vez do simples /dev/urandom é outro hack. A JVM não entende o valor da opção de outra forma.

Esteja ciente deste problema se você tentar configurar o weblogic no SO baseado em UNIX.

    
por 18.04.2011 / 19:05
0

Pode haver vários motivos para essa verificação no link abaixo:

link

Além disso, se você começar a se deparar aleatoriamente entre eles, pode haver a possibilidade de que qualquer servidor gerenciado tenha saído do cluster e o weblogic esteja tentando conectá-lo para coletar dados do jmx.

Nesse caso, depois de matar o console do servidor gerenciado, ele chegará ao estado normal.

Para mais depuração em tais cenários, o log dos administradores pode ser verificado durante a lentidão, junto com os logs do nodemanger.

    
por 30.05.2015 / 17:41