Problema Componente java.lang.OutOfMemory[RESOLVIDO]

Spring é um framework ou biblioteca brasileiro? :shock: Muitos aqui têm o hábito de postar aqui porque a galera do Vraptor é mais ativa nas respostas, porém acima de tudo deve-se respeitar as normas do fórum e postar as coisas nos seus devidos lugares.

Spring é um framework ou biblioteca brasileiro? :shock: Muitos aqui têm o hábito de postar aqui porque a galera do Vraptor é mais ativa nas respostas, porém acima de tudo deve-se respeitar as normas do fórum e postar as coisas nos seus devidos lugares.

Bom eu só postei aki porque pelo que sei a implementação padrão do vraptor está usando o spring…e pode ser que o “spring” não seja o culpado dos estouros…não tenho experiencia pra dizer que a culpa é de 1 ou outro framework…apenas pedindo ajuda de como saber isso…o componente é vraptor…eu peguei no livro de receitas do site …entao tudo me leva a crer que aqui que devo pedir ajuda pois senao não estaria postando…

peguei no link
http://vraptor.caelum.com.br/cookbook/job-scheduling-com-vraptor3-e-spring/

package br.com.webtia.contrato.scheduler;

import org.apache.log4j.Logger;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.cfg.Configuration;
import org.joda.time.DateTime;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.support.CronTrigger;

import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.webtia.contrato.daos.ContratoDao;
import br.com.webtia.contrato.interfaces.ApplicationTask;

@Component
@ApplicationScoped
public class RescindeContratoTask implements ApplicationTask {
	static Logger logger = Logger.getLogger(RescindeContratoTask.class); 
	public RescindeContratoTask(TaskScheduler scheduler) {
    	this.schedule(scheduler);
    }
    public void schedule(TaskScheduler scheduler) {
        scheduler.schedule(this, new CronTrigger("1 0 0 * * *"));
    }
	@Override
	public void run() {
		//Rescisão de contrato
		long start = System.currentTimeMillis();
		Configuration conf = new AnnotationConfiguration().configure();
		SessionFactory factory = conf.buildSessionFactory();
		Session session = factory.openSession();
		Transaction transaction = null;
		try {
			transaction = session.beginTransaction();
			ContratoDao daoContrato = new ContratoDao(session,null,null);
			daoContrato.rescindeContratoScheduled();
			transaction.commit();
		} finally {
			if (transaction != null && transaction.isActive()) {
				transaction.rollback();
			}
			session.close();
		}
		long end = System.currentTimeMillis();
		logger.info("Task RescindeContratoTask executada em =>"+(end-start)+" ms - Ultima execução =>"+new DateTime());
	}
}

Esse é o componente que estou utilizando seguindo a implementação do link do livro de receitas…

Agradeço qualquer ajuda…

Essa exceção estoura em tantos pontos diferentes que é até difícil de saber direito o que está acontecendo.. Veja:

Exception in thread "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1" java.lang.OutOfMemoryError: Java heap space   
    at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:819)   
	
Warning: Exception was: java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.<init>(Unknown Source)   

java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
    at java.util.LinkedList.clone(LinkedList.java:853)   
	
java.lang.OutOfMemoryError: Java heap space   
    at java.util.Arrays.copyOfRange(Arrays.java:3221)

Ou seja, um aconteceu acessando o BD, outro fazendo parse de XML, outro clonando uma lista e outro copiando um array. O que dá a entender é que a carga do servidor de produção está um tantinho mais alta do que onde foi desenvolvido e, teoricamente, um aumento na memória da JVM deve resolver o problema. Como estão configurados os parâmetros de memória?

[]´s

asaudate:

Essa exceção estoura em tantos pontos diferentes que é até difícil de saber direito o que está acontecendo.. Veja:

Exception in thread "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1" java.lang.OutOfMemoryError: Java heap space   
    at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:819)   
	
Warning: Exception was: java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.<init>(Unknown Source)   

java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
java.lang.OutOfMemoryError: Java heap space   
    at java.util.LinkedList.clone(LinkedList.java:853)   
	
java.lang.OutOfMemoryError: Java heap space   
    at java.util.Arrays.copyOfRange(Arrays.java:3221)

Ou seja, um aconteceu acessando o BD, outro fazendo parse de XML, outro clonando uma lista e outro copiando um array. O que dá a entender é que a carga do servidor de produção está um tantinho mais alta do que onde foi desenvolvido e, teoricamente, um aumento na memória da JVM deve resolver o problema. Como estão configurados os parâmetros de memória?

[]´s

Entao na homologação aki que utilizo minha maquina é um intel core i5 com 4gbRAM ...nao coloco uma configuração pradrao no tomcat.....

no servidor de produção é ma maquina virtual onde roda o servidor tomcat dentro com memoria virtual de 1gb apenas que na verdade é compartilhada de um servidor real..que nao sei a especificação....talve esteja ai o problema...sem uma configuração padrão tambem de memória ..

quando nao se define nada em JAVA_OPTS no start do servidor a jvm nao se vira com o que tem???Seria ideal configurar a variavel JAVA_OPTS com Xmx e Xms -XX:PermSize???
Pra 1 giga de ram qual seria o ideal?

O local onde ocorre o estouro de memória não é relevante.
O problema é que a memória está sendo consumida e ocasionando falta.

Um dos dois (ou os dois) motivos:
1- A configuração de memória está mal dimensionada.
2- A aplicação não libera os recursos utilizados (connection, resultset, statement, jms, etc)

Vamos supor que o sistema fica dois dias rodando e no terceiro dá falta de memória.

Se neste terceiro dia, a carga de uso foi como nos outros dois dias, então a probabilidade de estar ocorrendo o segundo item é maior.
Se neste terceiro dia, a carga foi anormal e muito maior que nos outros dois dias, então é possível que seja 1.

Se você aumenta a memória da JVM e o problema passa a acontecer no 5o dia ao invés do 3o, você só postergou o problema.

Eu apostaria mais no item 2.

boneazul, desculpe, no post não citava que estava usando vraptor, por isso minha indagação. :thumbup:

Mas vamos lá… o tomcat não é lá um bom container para coisas muito críticas. Um dos graves problemas dele é de ficar objetos presos em memória, principalmente se tratando de atributos estáticos. Não lembro bem o link desses problemas, mas se você fizer uma pesquisa por tomcat memory leak você vai encontrar algumas coisas interessantes. Não faço isso porque estou postando do celular, e é um “pouco tenso” fazer pesquisar em uma tela pequena.

Uma coisa que você pode fazer é verificar se o causados do out-of-memory é esse componente e tentar através de um profiler entender o que está causando o out-of-memory.

Não importa se você tem um 1pb de memória, a VM nunca vai usar isso. O máximo que uma vm em intel32 chega é 1.7G por instância (preciso procurar as fontes disso para confirmar).

Tente algo como abaixo. Lembrando que se você está em algum servidor com missão critica, você precisa fazer um ajuste mais fino nesses parametros, além de iniciar com a opção -server (o padrão é -client). Sai um artigo na Java Magazine há uns 6 meses atrás sobre esses parametros todos da JVM.
-Xms600m -Xmx1024m

Ele está usando Hibernate com Spring, e ambos tomam os cuidados de liberar esse tipo de recurso (quanto aos recursos de BD). Quanto aos recursos de JMS, duvido muitíssimo que seja, porque afinal, ele está usando um Tomcat. Não me ocorre mais nenhum tipo de recurso, e vc?

[]´s

Post duplicado.

To muito cismado com a factory desse scheduler que peguei...

package br.com.webtia.contrato.scheduler;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

import org.apache.log4j.Logger;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler;

import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.caelum.vraptor.ioc.ComponentFactory;

@Component
@ApplicationScoped
public class TaskSchedulerFactory implements ComponentFactory<TaskScheduler> {
	private static Logger logger = Logger.getLogger(TaskSchedulerFactory.class);
    private ThreadPoolTaskScheduler scheduler;
    
    @PostConstruct
    public void create() {
    	logger.info("Iniciando nova threadpool scheduler");
        scheduler = new ThreadPoolTaskScheduler();
        scheduler.initialize();
    }
    
    public TaskScheduler getInstance() {
        return scheduler;
    }
    
    @PreDestroy
    public void destroy() {
    	logger.info("Destruindo threadpool scheduler");
        scheduler.destroy();
    }
    
}

Ele sempre inicia o scheduler mais ele nunca destroy....nao entendi muito bem o pq??

A rotina de email roda de 5 em 5 minutos....levando em conta que o servidor apresenta esse estouro geralmente no fim do dia é provavel isso estar gerando problema,ou nao,em todo caso baixei o jprofiler pra fazer testes mais tarde......

Problema de session do hibernate num deve ser pq utilizo o custom provider ja implementado do vraptor e os componentes que fiz abre e fecha o recurso corretamente tambem...

só esse scheduler que nao entra nunca nesse logger falando que ele foi destruido......ele teria ou nao que ser destruido??

obrigado por enquanto pelas respostas....

Bom, aí depende… vc diz que ele foi criado mas não foi destruído, mas foi criado QUANTAS vezes? Notei que ele tem o escopo de aplicação , então, é normal que ele não tenha sido destruído. Só não é normal se ele for criado várias vezes…

[]´s

asaudate:

Bom, aí depende… vc diz que ele foi criado mas não foi destruído, mas foi criado QUANTAS vezes? Notei que ele tem o escopo de aplicação , então, é normal que ele não tenha sido destruído. Só não é normal se ele for criado várias vezes…
[]´s

é o log so aponta uma vez pra criação …ele não é criado duas vezes…caramba viu…ta foda…nao tem mais onde procurar que não esteja fechando recurso…vo dar uma olhada no jprofiler hoje a noite e subir pra ver o q ta pegando…amanha posto as conclusões…abraços…

Achei estranho algumas coisas… porque você sempre cria uma factory do hibernate na hora que usa o scheduler? Você não pode usar os componentes próprios do vraptor para isso?

• Não sei se é só comigo que acesso pelo celular, mas esse log enorme que você colocou quase trava meu navegador.

garcia-jj:

Achei estranho algumas coisas… porque você sempre cria uma factory do hibernate na hora que usa o scheduler? Você não pode usar os componentes próprios do vraptor para isso?

• Não sei se é só comigo que acesso pelo celular, mas esse log enorme que você colocou quase trava meu navegador.

é meu navegador tb da de travar mais isso é devido ao syntaxhighliter que demora pra pintar as cores das tags code…ja diminui o tamanho do log com trechos que realmente interessam…

Como usaria “os componentes” do vraptor pra isso??Poderia postar um trecho do código que voce acha ideal???
Bom eu uso a factory do hibernate pra poder usar o dao que tem como dependencia a session do hibernate ja que nao pude injetar o dao no construtor ja que o componente é applicationscoped e a injecao de dependencia parece nao funcionar ja que o dao esta em escopo de request…mas teria algum problema invocar essa factory ai???

Bom vamos aos dados do profiler…bom realmente é a scheduler que ta comendo a memoria e não está liberando recurso em algum ponto…vo colocar algumas figuras dos print do jprofiler pra voces verem a diferença e ve se conseguer me ajudar com isso …bom o teste básico que eu fiz foi

1 - Desligar todos scheduler e ver a carga do sistema por 2:30 segundos …

Pelo que analisei nos graficos depois que a aplicação sobe ele sempre mantem se estavel…entre 70 e 90mb de memoria…e load de cpu muito baixo…
O numero de threads tambem em torno de 22 sendo que uso 10 pra uso do pool de conexões do c3p0 ->(por default ele usa 3) e o resto da main,etc…

Ou seja super leve …

2 - Agora vo ligar 1 scheduler e colocar ele pra rodar de 10 em 10 segundos com 1:30 segundos…

Pelo que analisei nos graficos depois que a aplicação sobe o aumento de memoria é sempre crescente quase 400 mega em comparação com os 70 alem do load da cpu ficar altissimo…e nunca se mantem…
O numero de threads subiu muito tambem para 128 mais ou menos…

Não é possivel que esteja custando tanto uma simples tarefa dessa…

2010/6/10/e23dbffb7591fa2d464b94fdbff225a0_31404.jpg_1021×671 118 KB

2010/6/10/f823069cf7f86406cba39e3f29338703_31404.jpg_999×555 82.5 KB

2010/6/10/1c061d2b8d4a1265ab8ed4f1f6d57713_31404.jpg_1020×521 84 KB

boneazul:

Bom vamos aos dados do profiler…bom realmente é a scheduler que ta comendo a memoria e não está liberando recurso em algum ponto…vo colocar algumas figuras dos print do jprofiler pra voces verem a diferença e ve se conseguer me ajudar com isso …bom o teste básico que eu fiz foi

1 - Desligar todos scheduler e ver a carga do sistema por 1:30 segundos …

Pelo que analisei nos graficos depois que a aplicação sobe ele sempre mantem se estavel…entre 70 e 90mb de memoria…
O numero de threads tambem em torno de 22 sendo que uso 10 pra uso do pool de conexões do c3p0 ->(por default ele usa 3) e o resto da main,etc…

Ou seja super leve …

2 - Agora vo ligar 1 scheduler e colocar ele pra rodar de 10 em 10 segundos com o mesmo tempo…

Pelo que analisei nos graficos depois que a aplicação sobe o aumento de memoria é sempre crescente e nunca se mantem…
O numero de threads subiu muito tambem para 128 mais ou menos…

e o ultimo grafico das threads …parece que a cada chamada que faz do recurso ou seja o scheduler é executado …o c3p0 chama 10 threads pra fazer o servio do pool eles não são liberados ai passa 10 segundos elel chama mais 10 ai ja fica 20 pendurada e por ai vai…ai num há jvm que de conta…kkkkk

Alguma ideia ??? num queria partira pra um cron da vida rodando java…ja que o spring tem esse recurso…e deus abençoe o jprofiler…

2010/6/10/5d5de871b44e1c3220d1780d18014ac5_31404.jpg_979×572 113 KB

Meu caro,

Poste alguns códigos principais da sua aplicação, onde utiliza recursos de banco, fila, datasources, poolm etc. Posta também alguns arquivos de configuração xml relacionados a recursos

Ainda mantenho minha aposta de que em algum ponto sua app não está liberando recursos. O fato de utilizar frameworks como hibernate, spring, etc … não elimina a possibilidade de estar causando leak.

CarvalR2:

Meu caro,

Poste alguns códigos principais da sua aplicação, onde utiliza recursos de banco, fila, datasources, poolm etc. Posta também alguns arquivos de configuração xml relacionados a recursos

Ainda mantenho minha aposta de que em algum ponto sua app não está liberando recursos. O fato de utilizar frameworks como hibernate, spring, etc … não elimina a possibilidade de estar causando leak.

Eu achei o ponto do leak…é ligado ao scheduler quando tiro o scheduler de funcionamento não há leak algum…é algum ponto nesse scheduler que não libera recurso…eu resolvi de uma maneira menos portavel pois tava meio urgente isso…usando o cron chamando uma url por wget …coisa que não queria ter feito…

bom vai la o código da implementação do scheduler…

Interface task

package br.com.webtia.contrato.interfaces;

import org.springframework.scheduling.TaskScheduler;

public interface Task extends Runnable {
    void schedule(TaskScheduler scheduler);
}

Interface application task

package br.com.webtia.contrato.interfaces;

public interface ApplicationTask extends Task {
}

Factory de schedulers

package br.com.webtia.contrato.scheduler;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

import org.apache.log4j.Logger;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler;

import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.caelum.vraptor.ioc.ComponentFactory;

@Component
@ApplicationScoped
public class TaskSchedulerFactory implements ComponentFactory<TaskScheduler> {
	private static Logger logger = Logger.getLogger(TaskSchedulerFactory.class);
    private ThreadPoolTaskScheduler scheduler;
    
    @PostConstruct
    public void create() {
    	logger.info("Iniciando nova threadpool scheduler");
        scheduler = new ThreadPoolTaskScheduler();
        scheduler.initialize();
    }
    
    public TaskScheduler getInstance() {
        return scheduler;
    }
    
    @PreDestroy
    public void destroy() {
    	logger.info("Destruindo threadpool scheduler");
        scheduler.destroy();
    }
    
}

package br.com.webtia.contrato.scheduler;

import java.io.PrintWriter;
import java.io.StringWriter;
import java.util.Calendar;
import java.util.List;

import org.apache.log4j.Logger;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.cfg.Configuration;
import org.joda.time.DateTime;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.support.CronTrigger;

import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.webtia.contrato.daos.EmailPanelDao;
import br.com.webtia.contrato.interfaces.ApplicationTask;
import br.com.webtia.contrato.models.EmailPanel;
import br.com.webtia.contrato.util.SendMail;

@Component
@ApplicationScoped
public class EmailSendTask implements ApplicationTask {
	static Logger logger = Logger.getLogger(EmailSendTask.class); 
	public EmailSendTask(TaskScheduler scheduler) {
    	this.schedule(scheduler);
    }
    public void schedule(TaskScheduler scheduler) {
    	scheduler.schedule(this, new CronTrigger("0/10 * * * * *"));
    }
	@Override
	public void run() {
		
		//Disparo de email
		long start = System.currentTimeMillis();
		Configuration conf = new AnnotationConfiguration().configure();
		SessionFactory factory = conf.buildSessionFactory();
		Session session = factory.openSession();
		Transaction transaction = null;
		try {
			transaction = session.beginTransaction();
			EmailPanelDao daoEmailPanel = new EmailPanelDao(session);
			List<EmailPanel> emails  = daoEmailPanel.listAllNotSended();
			for(EmailPanel email : emails){
				try {
					SendMail.sendMail(email.getTo(),email.getFrom(), email.getSubject(), email.getMessage());
					email.setSended('S');
					email.setSendeddate(Calendar.getInstance().getTime());
					email.setProblem("");
				} catch(Exception e) {
					StringWriter w = new StringWriter();
					email.setSended('N');
					e.printStackTrace(new PrintWriter(w));
					email.setProblem(w.toString());
				}
				daoEmailPanel.update(email);
			}
			
			transaction.commit();
		} finally {
			if (transaction != null && transaction.isActive()) {
				transaction.rollback();
			}
			session.close();
		}
		long end = System.currentTimeMillis();
		logger.info("Task EmailSendTask executada em =>"+(end-start)+" ms - Ultima execução =>"+new DateTime());
	}
}

O leak esta nesse meio ai…pq quando desligo essa ultima classe o servidor nao é sobrecarregado se voce ver no profile…algum ponto nesse trechos estao comendo recurso…
deve ser a ligação entre a extensão de runnable e o ponto da criacao da session do hibernate e o c3p0 algo nesse sentido…nao tenho muuita experiencia pra saber exato o ponto que deveria liberar e nao libera…

Boneazul, Eu fiz um teste com o job scheduling conforme o cookbook só que utilizei, conforme o sugerido, uma classe PrototypedDao (com @PrototypeScoped)

Talvez fosse interessante testar utilizando essa classe.

No meu teste a classe ficou desta forma (como exemplo):

@Component
@PrototypeScoped
public class PrototypeDao {
	
	private Session session;
	
	public PrototypeDao(SessionFactory sessionFactory) {
		this.session = sessionFactory.openSession();
	}
	public void adiciona(Divisao d) { 
		this.session.save(d); 
	}
	protected Session getSession() {
		return session;
	}
}

Lagaffe:

Boneazul, Eu fiz um teste com o job scheduling conforme o cookbook só que utilizei, conforme o sugerido, uma classe PrototypedDao (com @PrototypeScoped)

Talvez fosse interessante testar utilizando essa classe.

No meu teste a classe ficou desta forma (como exemplo):

@Component
@PrototypeScoped
public class PrototypeDao {
	
	private Session session;
	
	public PrototypeDao(SessionFactory sessionFactory) {
		this.session = sessionFactory.openSession();
	}
	public void adiciona(Divisao d) { 
		this.session.save(d); 
	}
	protected Session getSession() {
		return session;
	}
}

é nao pensei em fazer esse teste pra ver como se comporta …

entao mas onde eu usaria esse prototype scoped??
poderia me dar um exemplo completo??ou pegar esse meu codigo e modificar a parte relevante…

obrigado por enquanto a todos que estão ajudando…

Meu caro,

Por favor, volte as configurações anteriores do Spring e nos faça um teste na EmailSendTask . De nada custa:

• Use transaction.wasCommitted() no finally para dar o rollback;
• Finalize a factory no finally : factory.close();
• Dentro do catch (Exception e) :
  . Coloque tudo dentro de um novo try/catch/finally e declare uma variavel para PrintWriter:

PrintWriter p = null;

try {

…

} finally {

if (p!= null) { p.close(); }

}

Por favor, faça os testes e nos retorne o resultado. Se possível, inclua também o código fonte de SendMail.java

Deve ser algo assim:

@Component
@PrototypeScoped
public class EmailPrototypedDao {
	
	private Session session;
	
	public EmailPrototypedDao(SessionFactory sessionFactory) {
		this.session = sessionFactory.openSession();
	}
	public void update(EmailPanel emailPanel) {
		this.session.merge(emailPanel);
	}
	public List<EmailPanel> listAllNotSended() { 
		return suaQuery; 
	}
	protected Session getSession() {
		return session;
	}
}

e naEmailSendTask o método run:

@Override
	public void run() {// aqui roda a aplicação
		List<EmailPanel> emails  = this.emailPrototypedDao.listAllNotSended();
		for(EmailPanel email : emails){  
                 try {  
                     SendMail.sendMail(email.getTo(),email.getFrom(), email.getSubject(), email.getMessage());  
                     email.setSended('S');  
                     email.setSendeddate(Calendar.getInstance().getTime());  
                     email.setProblem("");  
                 } catch(Exception e) {  
                     StringWriter w = new StringWriter();  
                     email.setSended('N');  
                     e.printStackTrace(new PrintWriter(w));  
                     email.setProblem(w.toString());  
                 }  
                 this.emailPrototypedDao.update(email);  
             }  
	}

inclua no inicio do código:

final private EmailPrototypeDao emailprototypeDao;

e inclua o EmailPrototypedDao no contrutor

Lagaffe:

Deve ser algo assim:

@Component
@PrototypeScoped
public class EmailPrototypedDao {
	
	private Session session;
	
	public EmailPrototypedDao(SessionFactory sessionFactory) {
		this.session = sessionFactory.openSession();
	}
	public void update(EmailPanel emailPanel) {
		this.session.merge(emailPanel);
	}
	public List<EmailPanel> listAllNotSended() { 
		return suaQuery; 
	}
	protected Session getSession() {
		return session;
	}
}

e naEmailSendTask o método run:

@Override
	public void run() {// aqui roda a aplicação
		List<EmailPanel> emails  = this.emailPrototypedDao.listAllNotSended();
		for(EmailPanel email : emails){  
                 try {  
                     SendMail.sendMail(email.getTo(),email.getFrom(), email.getSubject(), email.getMessage());  
                     email.setSended('S');  
                     email.setSendeddate(Calendar.getInstance().getTime());  
                     email.setProblem("");  
                 } catch(Exception e) {  
                     StringWriter w = new StringWriter();  
                     email.setSended('N');  
                     e.printStackTrace(new PrintWriter(w));  
                     email.setProblem(w.toString());  
                 }  
                 this.emailPrototypedDao.update(email);  
             }  
	}

inclua no inicio do código:

final private EmailPrototypeDao emailprototypeDao;

e inclua o EmailPrototypedDao no contrutor

entendi agora o problema é que uso o daoEmail na aplicação em escopo de request tamem…

PrototypedScope atende o escopo de request???

CarvalR2:

Meu caro,

Por favor, volte as configurações anteriores do Spring e nos faça um teste na EmailSendTask . De nada custa:

• Use transaction.wasCommitted() no finally para dar o rollback;
• Finalize a factory no finally : factory.close();
• Dentro do catch (Exception e) :
  . Coloque tudo dentro de um novo try/catch/finally e declare uma variavel para PrintWriter:

PrintWriter p = null;

try {

…

} finally {

if (p!= null) { p.close(); }

}

Por favor, faça os testes e nos retorne o resultado. Se possível, inclua também o código fonte de SendMail.java

package br.com.webtia.contrato.scheduler;

import java.io.PrintWriter;
import java.io.StringWriter;
import java.util.Calendar;
import java.util.List;

import org.apache.log4j.Logger;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.cfg.Configuration;
import org.joda.time.DateTime;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.support.CronTrigger;

import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.webtia.contrato.daos.EmailPanelDao;
import br.com.webtia.contrato.interfaces.ApplicationTask;
import br.com.webtia.contrato.models.EmailPanel;
import br.com.webtia.contrato.util.SendMail;

@Component
@ApplicationScoped
public class EmailSendTask implements ApplicationTask {
	static Logger logger = Logger.getLogger(EmailSendTask.class); 
	public EmailSendTask(TaskScheduler scheduler) {
    	this.schedule(scheduler);
    }
    public void schedule(TaskScheduler scheduler) {
    	scheduler.schedule(this, new CronTrigger("0/10 * * * * *"));
    }
	@Override
	public void run() {
		
		//Disparo de email
		long start = System.currentTimeMillis();
		Configuration conf = new AnnotationConfiguration().configure();
		SessionFactory factory = conf.buildSessionFactory();
		Session session = factory.openSession();
		Transaction transaction = null;
		try {
			transaction = session.beginTransaction();
			EmailPanelDao daoEmailPanel = new EmailPanelDao(session);
			List<EmailPanel> emails  = daoEmailPanel.listAllNotSended();
			for(EmailPanel email : emails){
				try {
					SendMail.sendMail(email.getTo(),email.getFrom(), email.getSubject(), email.getMessage());
					email.setSended('S');
					email.setSendeddate(Calendar.getInstance().getTime());
					email.setProblem("");
				} catch(Exception e) {
					PrintWriter p = null;
					try {
						email.setSended('N');
						StringWriter w = new StringWriter();
						p=new PrintWriter(w);
						e.printStackTrace(p);
						email.setProblem(w.toString());
					} finally {
						if (p!= null) { p.close(); }
					} 
				}
				daoEmailPanel.update(email);
			}
			
			transaction.commit();
		} finally {
			if (transaction.wasCommitted() && transaction.isActive()) {
				transaction.rollback();
			}
			session.close();
			factory.close();
		}
		long end = System.currentTimeMillis();
		logger.info("Task EmailSendTask executada em =>"+(end-start)+" ms - Ultima execução =>"+new DateTime());
	}
}

Bom segundo suas modificações ficaria assim como acima??

código do sendMail

package br.com.webtia.contrato.util;

import java.util.Properties;

import javax.mail.Authenticator;
import javax.mail.Message;
import javax.mail.PasswordAuthentication;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

import org.apache.log4j.Logger;


public class SendMail {
	public static void sendMail(String to,String from, String subject, String message) throws Exception {
		Logger logger=Logger.getLogger(SendMail.class);
		Properties props = new Properties();
		props.put("mail.smtp.host", "localhost");
		props.put("mail.smtp.auth", "true");
		props.put("mail.mime.charset", "ISO-8859-1");

		Session session = Session.getDefaultInstance(props,
				new Authenticator() {
					protected PasswordAuthentication getPasswordAuthentication() {
						return new PasswordAuthentication("usuario",
								"senha");
					}
				});
		Message msg = new MimeMessage(session);
		if(to.contains(",")){
			String mails[]=to.split(",");
			InternetAddress adresses[]=new InternetAddress[mails.length];
			for(int i=0;i<mails.length;i++){
				adresses[i]=new InternetAddress(mails[i]);
			}
			msg.setRecipients(Message.RecipientType.TO, adresses);
		} else msg.setRecipient(Message.RecipientType.TO, new InternetAddress(to));
		if(from.equals("")) msg.setFrom(new InternetAddress("[email removido]"));
		else msg.setFrom(new InternetAddress(from));
		msg.setSubject(subject);
		msg.setContent(message, "text/html");
		try {
			Transport.send(msg);
		} catch(Exception e) {
			logger.debug("Dados do email ---------------------");
			logger.debug("From : "+from);
			logger.debug("To : "+to);
			logger.debug("Subject : "+subject);
			logger.debug("Message : "+message);
			logger.debug("---------------------");
			logger.info("Não conseguiu disparar email "+e.getMessage());
		}
		
	}
}

Sim. Após estas alterações, como está o consumo ?

No livro de receitas está informando:

No livro de receitas está informando:

O Spring possui um escopo chamado prototype que define que o componente terá uma nova instância sempre que for requisitada… Este escopo serve para definir compenentes utilizados por tasks em escopo de application que naturalmente não são singletons, como DAO?s.

Deste modo, será criado uma instância do seu DAO para cada requisição de instância (lê-se: sempre que você receber uma instância pelo construtor, será uma nova), assim como uma Session separada.

“Este escopo serve para definir compenentes utilizados por tasks em escopo de application”

entao como tinha dito anteriormente eu preciso desse muitas vezes no escopo de request em diversos ponto do programa nao vou recriar um componente pra cadas escopo pra repetir código…tem como falar que um componente pode estar em dois escopos ao mesmo tempo?? no caso no escopo prototyped e request??

@CarvalR2

Cara num é que era o close da factory mesmo…rodei o profiler aki de novo com as alterações…pq dificilmente ele iria entrar no exception do close do printwriter…agora com o profiler se mantem estavel em 108 megas…e 11 threads…
isso rodando de 10 em 10 segundos…o que seria pra estressar o ambiente mesmo…e a carga se mantem…

Obrigado pela paciencia e ajuda de voces…vo voltar o eskema pra rodar no produção com esse close que faltou…

Antes de minha barba ficar branca, eu aprendi isso com um amigo muito experiente:

• Sempre procure metodos close(), quit(), finalize(), release() , etc nestes objetos de frameworks e na propria api java, quando os utilizar. Pois isso salva fim de semana.

(e vale muito para mes de copa do mundo)

Fico feliz em repassar esse conhecimento. Até +

CarvalR2:

Antes de minha barba ficar branca, eu aprendi isso com um amigo muito experiente:

• Sempre procure metodos close(), quit(), finalize(), release() , etc nestes objetos de frameworks e na propria api java, quando os utilizar. Pois isso salva fim de semana.

(e vale muito para mes de copa do mundo)

Fico feliz em repassar esse conhecimento. Até +

É entao eu ja tinha mudado o eskema desse scheduler pra nao ficar de barba branca…kkkk…como disse pra uma maneira menos portavel mas que resolveu…

…mas sou de ir atras o porque nao estava funcionando…agora vou ficar mais esperto…com esse tipo de coisa ou seja quando eu “o programador burraldo fizer as coisas” realmente escapou akele close fiquei tão preocupado em fechar a session que esqueci da factory…

Valeu mesmo…

Cara, a partir de agora vc vai ficar tão de olho nisso, que nunca mais vai ter problema de leak. E se tiver, vai resolver rápido!

falowz

Mais importante que isso é ler a documentação ao invés de programar na base da tentativa e erro.

Já que o culpado inicial de tudo foi aquele componente que está no cookbook minha sugestão é retira-lo e notificar o autor. Logo vamos ter uma sindrome de “out-of-memory” de tanta gente fazendo copy and paste de código bugado.

Garcia,

Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?

Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.

Se estiver equivocado, por favor me informe.

Lagaffe:

Garcia,

Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?

Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.

Se estiver equivocado, por favor me informe.

Tá certo, acabei não lendo com atenção o tópico e falei besteira :oops:

Olhei com calma a sugestão do cookbook e realmente me parece que está tudo certo, visualmente falando. Os objetos que teriam problema em criar multiplas instâncias e não fechar estão todos como application-scoped. Me parece certo mesmo.

garcia-jj:

Lagaffe:

Garcia,

Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?

Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.

Se estiver equivocado, por favor me informe.

Tá certo, acabei não lendo com atenção o tópico e falei besteira :oops:

Olhei com calma a sugestão do cookbook e realmente me parece que está tudo certo, visualmente falando. Os objetos que teriam problema em criar multiplas instâncias e não fechar estão todos como application-scoped. Me parece certo mesmo.

o componente esta ok sim…o erro foi da implementacao que faltou fechar a Sessionfactory por isso dava o vazamento de memória…é q na epoca nao havia tambem o suporte a prototypedScope no vraptor…que hoje tem…

mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…

com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??

boneazul:

mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…

com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??

Não, você não pode injetar um requested-scope em um application scoped. Mas o contrário você pode.

Isso, a principio, me parece um erro de lógica. Mas pensando bem não vejo um problema nisso, e até o EJB permite você fazer isso, já que em um EJB Scheduler do 3.1 eu tenho stateless session beans injetados em um scheduler.

boneazul wrote:

mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…

com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??

Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.

A observação do Garcia é interessante. Talvez permita uma solução mais simples.

Lagaffe:

boneazul wrote:

mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…

com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??

Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.

A observação do Garcia é interessante. Talvez permita uma solução mais simples.

A solução que voce dizem é passar o dao para @ApplicationScoped??

boneazul:

Lagaffe:

Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.

A observação do Garcia é interessante. Talvez permita uma solução mais simples.

A solução que voce dizem é passar o dao para @ApplicationScoped??

Pois é, não entendo bem qual a diferença, isso a nivel de dao, de ser application. Se pensar no EJB, um stateful não deixa de ser um application scoped. Mas isso o Lucas que pode opinar melhor.

O problema seria você ter um session como atributo de classe, porém creio que se a session segue a idéia do entity-manager isso não será problema.