Closed renalexster closed 6 years ago
Complementando a informação.
Eu realizei um teste baixando o código do demoiselle e alterei a parte do parallelStream para stream(), o servidor não apresentou problemas com essa implementação.
@renalexster , fiz um pull request com tua sugestão: #119
Olá @joaquimpedrooliveira,
Alguma previsão de quando sai o novo release do demoiselle? E se essa alteração já vai estar presente?
Obrigado.
@renalexster, mandei o pull request mas não faço parte do time do Demoiselle. Acredito que o @botelhojp ou o @PauloGladson possam dar essa resposta.
Como o ajuste é bem pontual, vamos aceitar o pull request e gerar snapshot hoje. Fico aguardando avaliação para geração de versão final.
Gerada versão 3.0.3-SNAPSHOT. @renalexster, você poderia fazer a mesma avaliação de desempenho para essa versão?
@botelhojp, Realizei o mesmo teste de carga de antes, usando JMeter e agora não tive problemas de CPU load.
Como se pode perceber na imagem, após o encerramento do teste, o CPU volta a ficar IDLE.
Obrigado.
Olá @botelhojp,
Eu realizei o teste com o stream() e o servidor se comporta sem dead lock agora. Você sabe dizer se tem previsão de quando sai um novo release nos repositórios maven?
Olá @renalexster ,
Foi gerado a release 3.0.3, você já pode atualizar o pom.xml do projeto.
https://oss.sonatype.org/content/repositories/releases/org/demoiselle/jee/demoiselle-core/3.0.3/
Vou encerrar essa issue, qualquer coisa reabrimos.
Configurações do Ambiente
Descrição do Problema
Meu servidor Wildfly está apresentando Threads consumindo 100% de CPU por conta de um problema que acredito fortemente ser de paralelismo (concorrência).
Fiz uma análise detalhada do servidor e encontrei Threads relacionadas ao demoiselle-security, especificamente CorsFilter.java e SecurityFilter.java travando o pool de Threads do parallelStream do Java (ForkJoinPool)
O que acontece é que as classes CorsFilter.java e SecurityFilter.java do demoiselle-security utilizam o parallelStream para realizar um put em um Map do JAX-RS javax.ws.rs.container.ContainerResponseContext (ver imagem abaixo, linha 54, res.getHeaders().putSingle... )
O grande problema é que a implementação do res.getHeader() do resteasy, utiliza um Map do tipo TreeMap (que não é thread-safe, https://docs.oracle.com/javase/8/docs/api/java/util/TreeMap.html).
Portanto, o acesso concorrente no TreeMap está gerando em certo momento de saturação do sistema, um deadlock, causando CPU load muito alto e consequentemente perda de performance na aplicação.
Segue abaixo o print do status da JVM no momento do Lock, e o Thread dump (Full e apenas as Threads em Lock). Além da configuração detalhada do ambiente.
ThreadDump-FULL.txt ThreadsLOCK.txt