Tenho um WebService (axis) rodando no tomcat6 mas tenho problemas de memory leak ao fazer undeploy…
SEVERE: The web application [/adseg_teste] created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder@6c1b484b]) and a value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] (value [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl@73276b5f]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Olhei neste link e vi que alguns dos problemas de memory leak já estão resolvidos no tomcat7 porém criei um outro ambiente atualizado e o problema continua… e geralmente quando faço undeploy, uns 5 desses vazamentos são lançados para esta mesma classe (XMLUtils)…
Se alguém tiver alguma dica do que fazer para corrigir este problema, ficarei grato…
um dia li em um tópico que o ViniGodoy comentava (nao tenho certeza se foi aqui no guj) e falava que uma das grandes causas do vazamento de memória era o uso de variáveis estáticas… porém possuo algumas variáveis tais como as sessões dos usuários (da aplicação) e uma instância ConnectionManager que distribui as conexões do pool para cada requisição… porém mesmo anulando elas ao fazer undeploy o memory leak continua…
É errado o uso de variáveis estáticas neste caso? Mesmo quando seu uso é necessário?
E outra, mesmo que eu contorne este caso, não é certo que continuarei sem memory leak…
[quote=erico_kl]um dia li em um tópico que o ViniGodoy comentava (nao tenho certeza se foi aqui no guj) e falava que uma das grandes causas do vazamento de memória era o uso de variáveis estáticas… porém possuo algumas variáveis tais como as sessões dos usuários (da aplicação) e uma instância ConnectionManager que distribui as conexões do pool para cada requisição… porém mesmo anulando elas ao fazer undeploy o memory leak continua…
É errado o uso de variáveis estáticas neste caso? Mesmo quando seu uso é necessário?
E outra, mesmo que eu contorne este caso, não é certo que continuarei sem memory leak…[/quote]
você precisa usar a jvisualvm e ver em qual ponto da aplicação isso acontece. Sabendo o ponto você otimiza o bloco e vê o que acontece. O problema com esses estouros é que você não tem como saber em qual ponto da aplicação o problema acontece usando apenas impressão de pilha.
Normal meu amigo!! A nova versão do tomcat 7 apenas avisa que vc tem furos de memoria…sendo q ele mesmo não pode fazer nada pela sua app.
Agradeça pelo tomcat 7 agora pelo menos avisar…pq antes vc nem sabia…kkkkk
Vc precisa fazer o de sempre…localizar o lugar do vazamento e corrigir…no doc do tomcat 7 tem algumas dicas dos possiveis lugares que isso pode acontecer…
Seu logg ja ta falando que foi uma ThreadLocal (API da apache…) que foi guardada e não limpada no fim do request (1 dos lugares que acontece muito)…
veja http://fernandofranzini.wordpress.com/2011/09/05/escopo-thread-local/
[quote=juliocbq]
você precisa…[/quote]
Já acompanhei com o JVisualVM porém não achei nenhum lugar específico nele onde eu possa acompanhar os pontos de vazamento de memória…
[quote=FernandoFranzini]
Normal meu amigo!! A nova…[/quote]
Valeu, FernandoFranzini… vc me ajudando denovo hehe… eu li o seu artigo que vc mandou, mas de que forma posso tratar ThreadLocal (chamar o remove(), talvez) se eu nao utilizo explicitamente no projeto?
E tem outra… o pool de conexões está implementado diretamente no tomcat, então nao tenho acesso às ThreadLocal(s) que o tomcat cria…
corrija-me se eu estiver errado…
dei mais uma pesquisada mas ainda não achei solução para o problema…
e todas as memory leaks que acusam são de ThreadLocal… tem alguma forma de eu removê-las no listener acionado pelo undeploy?
[quote=erico_kl]dei mais uma pesquisada mas ainda não achei solução para o problema…
e todas as memory leaks que acusam são de ThreadLocal… tem alguma forma de eu removê-las no listener acionado pelo undeploy?[/quote]
sim…ThreadLocal.remove()
[quote=FernandoFranzini][quote=erico_kl]dei mais uma pesquisada mas ainda não achei solução para o problema…
e todas as memory leaks que acusam são de ThreadLocal… tem alguma forma de eu removê-las no listener acionado pelo undeploy?[/quote]
sim…ThreadLocal.remove()[/quote]
mas o método remove() da ThreadLocal não é estático (a ThreadLocal do pacote java.lang)…
vc se refere à alguma outra?
[quote=erico_kl][quote=FernandoFranzini][quote=erico_kl]dei mais uma pesquisada mas ainda não achei solução para o problema…
e todas as memory leaks que acusam são de ThreadLocal… tem alguma forma de eu removê-las no listener acionado pelo undeploy?[/quote]
sim…ThreadLocal.remove()[/quote]
mas o método remove() da ThreadLocal não é estático (a ThreadLocal do pacote java.lang)…
vc se refere à alguma outra?
O framework/camada/componente que alocou a threadlocal deve ser o cara responsável por retirar ela.
Foi vc que fez ou algum outra coisa?[/quote]
na verdade não… isso é o próprio axis/tomcat que aloca… e aí nao retira no final…
acho que esse é o grande problema… eu não tenho acesso à essas Threads que não são removidas…
É o axis sim…
Veja na documentação se vc consegue remover na unha em um listener de undeploy…caso não tenha…não tem geito!!
Vc ta usando um produto que tem vazamento de memoria dentro do container web.
blz… vou dar uma olhada sim…
au também estava vendo sobre o axis2 mas o que a própria documentação diz é que nao tem praticamente nada de similiar ao axis 1.x e aí eu teria uma grande mudança na estrutura, fora que teria que aprender toda a forma do axis2 trabalhar, o que, por enquanto, fica inviável…
no geral, é só esse problema que tive com o axis, o desempenho das aplicações é muito bom, e é um ws simples de se trabalhar… o único detalhe são esses memory leaks mesmo (não interferem diretamente no desempenho, mas são furos de memória que ficam lá…)
Da para sobreviver com ele sim…
Pode interferir dependendo do numero redeploys que vc fizer…
No seu caso, vc tera que reiniciar o container as vezes para limpar isso ai…
é isso que estamos fazendo…
quando fizemos um número considerável de undeploys no ambiente de produção, reiniciamos o tomcat… mas isso ocorre uma vez a cada 6 meses por aí… pois quem mais sofre com isso é o servidor de testes mesmo hehe…
[quote=erico_kl]é isso que estamos fazendo…
quando fizemos um número considerável de undeploys no ambiente de produção, reiniciamos o tomcat… mas isso ocorre uma vez a cada 6 meses por aí… pois quem mais sofre com isso é o servidor de testes mesmo hehe…
valeu[/quote]
É isso ai…