Foram feitas medições de utilização de memória, processamento e número de threads durante os testes e o principal problema encontrado foi relacionado ao SoapUI que é chamado por meio das classes que iniciam com Wsdl criada dentro do projeto e que não tem relação direta com o DBehave.
Estas classes ao serem utilizadas criam dezenas de threads e consomem muita memória e no final do processo não concluem a thread como já foi relatado no próprio foórum do SoapUI como mostra o seguinte link: https://community.smartbear.com/t5/SoapUI-Open-Source/SOAPUI-thread-end-troubleshooting/td-p/135702. O erro relatado no fórum foi exatamente o encontrado por nós na medições com o VisualVM.
A primeira sugestão para mitigar o problema é aumentar a memória utilizada pelos testes que hoje esta em 2Gb para 5Gb caso seja uma máquina com 8Gb.
Para aumentar a memória no Eclipse é necessário seguir os passos:
Com o projeto selecionado no Project Explorer
Menu superior Run
Sub menu Run Configurations...
Escolha o que deseja rodar na sessão JUnit do pailen esquerdo (Por exemplo: CCT_ExecutaCenariosGerais_ENTREGA_DE_CARGA)
4.1 Normalmente aparecerão configurações que já foram executadas, ou seja, se desejar executar outros casos de teste rode normalmente e depois faça este procedimento que ele irá aprecer na sessão dentro do JUnit
Acesse a aba Arguments
No campo VM arguments adicione os seguintes argumentos: -XX:MaxPermSize=5g -Xms5g -Xmx5g
Ficará da seguinte maneira: -ea -XX:MaxPermSize=5g -Xms5g -Xmx5g
Clique em Apply e depois Run para rodar com a configuração alterada
Lembrando que o aumento da memória no eclipe.ini não tem efeito na execução do teste.
A outra sugestão que é a que resolve o problema por completo é a criação de um Singleton para a instanciação da WsdlProject que é a principal consumidora de memória, segue a sugestão de classe:
public class WsdlProjectSingleton {
private static WsdlProject project = null;
public static WsdlProject getInstance() throws XmlException, IOException, SoapUIException {
String userDir = System.getProperty("user.dir");
if (project == null) {
project = new WsdlProject(userDir + "/" + Server.URL_Arquivo_SoapUi_Para_Geracao_De_Massas);
}
return project;
}
}
Em todos os locais aonde se faz um new WsdlProject(...) é necessário alterar para WsdlProjectSingleton.getInstance(). Fiz vários testes, um deles que durou quase 5 horas e a memória se comportou como o esperado sem subir como antes e atingiu no máximo 400mb aproximados.
Observação: todos os testes que realizei foi com a versão 1.5.4-SNAPSHOT.
Foram feitas medições de utilização de memória, processamento e número de threads durante os testes e o principal problema encontrado foi relacionado ao SoapUI que é chamado por meio das classes que iniciam com Wsdl criada dentro do projeto e que não tem relação direta com o DBehave.
Estas classes ao serem utilizadas criam dezenas de threads e consomem muita memória e no final do processo não concluem a thread como já foi relatado no próprio foórum do SoapUI como mostra o seguinte link: https://community.smartbear.com/t5/SoapUI-Open-Source/SOAPUI-thread-end-troubleshooting/td-p/135702. O erro relatado no fórum foi exatamente o encontrado por nós na medições com o VisualVM.
A primeira sugestão para mitigar o problema é aumentar a memória utilizada pelos testes que hoje esta em 2Gb para 5Gb caso seja uma máquina com 8Gb.
Para aumentar a memória no Eclipse é necessário seguir os passos:
Lembrando que o aumento da memória no eclipe.ini não tem efeito na execução do teste.
A outra sugestão que é a que resolve o problema por completo é a criação de um Singleton para a instanciação da WsdlProject que é a principal consumidora de memória, segue a sugestão de classe:
Em todos os locais aonde se faz um new WsdlProject(...) é necessário alterar para WsdlProjectSingleton.getInstance(). Fiz vários testes, um deles que durou quase 5 horas e a memória se comportou como o esperado sem subir como antes e atingiu no máximo 400mb aproximados.
Observação: todos os testes que realizei foi com a versão 1.5.4-SNAPSHOT.