Erro de espaço PermGen – Glassfish Server

Isso é memory leaks do carregador de classs. Cada vez que você reimplanta o aplicativo, um novo classloader é criado para ele e todas as classs do seu aplicativo são carregadas novamente. Isso consome memory no espaço permanente.

O classloader antigo e todas as suas classs carregadas devem ser coletadas como lixo, caso contrário você acabará tendo um espaço PermGen após a implantação várias vezes. Isso não funciona se um object carregado por um carregador de class externo contiver uma referência a qualquer object carregado pelo carregador de class antigo. Este artigo fornece uma boa explicação do problema.

Geralmente, os vazamentos do carregador de class são difíceis de analisar e às vezes difíceis de corrigir. Para descobrir por que os carregadores de classs antigos não são coletados como lixo, você precisa usar um criador de perfil. No JProfiler , use o heap walker, selecione os objects classfish do glassfish e use a visualização de referências de input para verificar os caminhos para as raízes do coletor de lixo.

A class do carregador de classs é chamada org.apache.servlet.jasper.JasperLoader . Aqui está uma captura de canvas de uma situação normal, em que o carregador de classs é mantido apenas por instâncias ativas de objects carregados.

Na sua situação, você deve ver referências de objects externos. Outra causa comum de um vazamento de carregador de class em contêineres da Web é um encadeamento de segundo plano que não é interrompido. O Google Guice, por exemplo, tem esse bug no 3.0.

(Aviso: minha empresa desenvolve o JProfiler)

Para resolver este problema (no sistema operacional baseado em linux), faça o seguinte

1) aumentar a memory (para que esse problema não ocorra com freqüência) configurando “domain.xml” em

/ glassfish / domain / domain1 / config

procurar por

-XX:MaxPermSize=

set it to higher value eg- 198m or 256m

2) mata o processo glassfish para liberar a porta em que estava rodando ( no meu caso foi 8686 ) terminal aberto (no sistema operacional linux) e tipo –

sudo netstat -npl | grep 8686

isso resultará em algo como …

tcp6 0 0 :::8686 :::* LISTEN 3452/java

próximo uso

kill -9 3452 para matar esse processo (3452 neste caso)

Agora tente começar glassfish, deve começar.

Se você estiver usando o Windows, tente matar o processo glassfish (java.exe * 32) com o Gerenciador de Tarefas e, em seguida, reinicie o servidor.

Esse problema ocorre com a implantação iterativa muitas vezes. Eu já enfrentei isso muitas vezes. Por favor, consulte o link JIRA abaixo para bug glassfish:

http://java.net/jira/browse/GLASSFISH-587