JSF+Hibernate+Jboss - SUPER URGENTE

Programação Java
#1

Pessoal, estou precisando de ajuda com grande urgência.
Desenvolvemos uma aplicação para coletar dados da produção, que consiste em 12 equipamentos wireless espalhados pela fábrica, rodando uma aplicação web java com hibernate sobre o Jboss 4.2.2 no Linux.
A aplicação acessa duas bases de dados: SQL server simplesmente para logon e controle de acesso e Oracle 10g para as transações.
Estamos utilizando o conceito de Open Session in View, sugerida pelo próprio hibernate, ou seja, utilizamos Threads para aquisição de sessões e Interceptors para interceptar toda requisição ao servidor e conseguir uma nova sessão juntamente com a transação. Dessa forma, nossa aplicação possui dois HibernateUtil, um para cada base, e a cada requisição identificamos a necessidade e abrimos a transação com o HibernateUtil correto.
Rodamos o sistema com essa arquitetura em fase experimental por praticamente 3 meses com apenas 2 equipamentos na fábrica e tudo funcionou sem problemas.
Bastou expandirmos a quantidade de equipamentos para o Jboss começar a parar constantemente por falta de memória. Detalhe: A head space do Jboss está definida em 1,5 Gb. Segue abaixo o trecho do log do jboss no momento do “OutOfMemory”:

23:50:59,136 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
java.lang.OutOfMemoryError: Java heap space
	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
	at java.lang.StringBuffer.append(StringBuffer.java:225)
	at org.hibernate.engine.EntityKey.toString(EntityKey.java:113)
	at java.lang.String.valueOf(String.java:2615)
	at java.lang.StringBuffer.append(StringBuffer.java:220)
	at org.hibernate.util.StringHelper.toString(StringHelper.java:171)
	at org.hibernate.loader.Loader.getRow(Loader.java:1164)
	at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:568)
	at org.hibernate.loader.Loader.doQuery(Loader.java:689)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
	at org.hibernate.loader.Loader.doList(Loader.java:2144)
	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2028)
	at org.hibernate.loader.Loader.list(Loader.java:2023)
	at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:95)
	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569)
	at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
	at br.com.cestari.util.dao.Dao.listarDesc(Dao.java:192)
	at br.com.cestari.apontamento.dao.ApontamentoDeProducaoDao.listarSomenteProdutivas(ApontamentoDeProducaoDao.java:211)
	at br.com.cestari.apontamento.handler.HorasProdutivasHandler.getApontamentosDeHoras(HorasProdutivasHandler.java:175)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:438)
	at org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverImpl.java:82)
	at org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELParserHelper.java:532)
	at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
	at org.apache.commons.el.UnaryOperatorExpression.evaluate(UnaryOperatorExpression.java:156)
	at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:383)
	at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1076)
	at org.ajax4jsf.component.UIDataAdaptor.processDecodes(UIDataAdaptor.java:973)

Ainda não conseguimos descobrir o motivo.
A única coisa que percebemos é que 90% dos casos de falta de memória ocorrem entre as 11 da noite e 1 da madrugada, exatamente no horário que rodam alguns jobs no oracle, e que podem deixar a base um pouco mais lenta.

Enfim, esse é nosso panorama.
Se por acaso alguém já tenha passado por algo parecido ou saiba indicar possíveis motivos ficarei enormemente agradecido.

Sds,

#2

O Oracle/SQL Server roda na mesma máquina do JBoss?

#3

Tenta aumentar a memoria da sua JVM.
Já tive problemas com OutOfMemoryError e isso resolvou.

Abraço.

#4

felipeguerra,

Não. São três máquinas totalmente independentes: Jboss, SQL e Oracle.

vinnymaran,
Já estamos com 1,5Gb disponíveis para o Jboss.
Será que preciso de mais??
Nem a porcaria do Windows Vista consome tanto assim…

#5

Talvez suas consultas do hibernate estejam carregando muitos objetos (tente filtra-las), ou você pode estar fazendo consultas recursivas(com o eagger configurado).

[]'s

#6

lcegatti,

Também suspeitei disso no início, entretanto as paradas são repentinas e sem padrão.
Por exemplo: sistema trabalha 2 semanas ininterruptos e de repente pára, aí trabalha 2 dias e pára de novo, depois fica mais 1 semana normal e por aí vai.

E o sistema é muito simples, tanto é que diariamente os usuários utilizam todas as suas funções. Se fosse algum problema com o hibernate ou algo do gênero ele deveria parar todos os dias.

Atualmente estamos controlando as threads do ambiente e percebemos que tem alguma coisa que em dado momento está aumentando as threads até parar o serviço. O sistema fica normalmente com threads variando entre 50 e 70. Todas as vezes que o sistema parou as threads foram aumentando rapidamente para 100, 200, 300 até dar OutOfMemory.

Infelizmente ainda não conseguimos identificar o problema. Estamos investigando e eliminando as possibilidades. Encontramos algo sobre problemas com rede wireles.
Entretanto, criamos um processo que fica monitorando as threads, e quando estão subindo repentinamente a gente reinicia o Jboss automaticamente. Dessa forma garantimos que o sistema fica on-line a todo momento, principalmente durante a madrugada quando não estamos aqui na empresa para socorrer.

#7