Atualização para versão 3.3.0

[Miguel Cartagena]

Caros,

Depois que fiz a atualização para versão 3.3.0 do vraptor, de vez em quando (geralmente nas primeiras requisições) acontece um erro (StackOverflow). Pelo stack, parece que o vraptor entrou em um loop infinito e estourou a memória. Segue a stack do erro (depois das reticências tem pelo menos mais mas 1000 linhas iguais):

AVISO: Error for /vraptor/transaction/store
java.lang.StackOverflowError
    at java.util.LinkedHashMap$LinkedHashIterator.<init>(Unknown Source)
    at java.util.LinkedHashMap$KeyIterator.<init>(Unknown Source)
    at java.util.LinkedHashMap$KeyIterator.<init>(Unknown Source)
    at java.util.LinkedHashMap.newKeyIterator(Unknown Source)
    at java.util.HashMap$KeySet.iterator(Unknown Source)
    at java.util.HashSet.iterator(Unknown Source)
    at com.google.common.collect.LinkedHashMultimap.createEntryIterator(LinkedHashMultimap.java:285)
    at com.google.common.collect.AbstractMultimap$ValueIterator.<init>(AbstractMultimap.java:1154)
    at com.google.common.collect.AbstractMultimap$ValueIterator.<init>(AbstractMultimap.java:1153)
    at com.google.common.collect.AbstractMultimap$Values.iterator(AbstractMultimap.java:1135)
    at java.util.AbstractCollection.addAll(Unknown Source)
    at java.util.HashSet.<init>(Unknown Source)
    at com.google.common.collect.Sets.newHashSet(Sets.java:208)
    at br.com.caelum.vraptor.interceptor.Graph.findLeaves(Graph.java:129)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:115)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:125)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:125)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:125)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:125)
    at br.com.caelum.vraptor.interceptor.Graph.removeLeaves(Graph.java:125)
    ...

Para informação: é uma aplicação rodando no GAE, utilizando objectify para persistência.

 

[Miguel Cartagena]

Outra informação que esqueci: Implementei um interceptor simples, sem configurações de after e before.

[Miguel Cartagena]

Fiz alguns testes (tirei meu interceptor, funcionou corretamente) e acho que compreendi o que está acontecendo por aqui. O cenário é o seguinte: quando a aplicação é carregada, três requisições são disparadas para o servidor, que chegam praticamente ao mesmo tempo.

11:44:55,605 DEBUG [VRaptor             ] VRaptor received a new request
11:44:55,605 DEBUG [VRaptor             ] VRaptor received a new request
11:44:55,605 DEBUG [VRaptor             ] VRaptor received a new request

O vraptor tem construir um grafo para ordenar os interceptors (é isso mesmo?) e uma exceção de concorrência é lançada:

java.util.ConcurrentModificationException
    at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(Unknown Source)
    at java.util.LinkedHashMap$EntryIterator.next(Unknown Source)
    at java.util.LinkedHashMap$EntryIterator.next(Unknown Source)
    at com.google.common.collect.AbstractMultimap$KeySet$1.next(AbstractMultimap.java:861)
    at com.google.common.collect.Iterators$5.next(Iterators.java:527)
    at com.google.common.collect.Iterators$3.next(Iterators.java:117)
    at br.com.caelum.vraptor.interceptor.Graph.addDummies(Graph.java:83)
    at br.com.caelum.vraptor.interceptor.Graph.orderTopologically(Graph.java:67)
    at br.com.caelum.vraptor.interceptor.Graph.topologicalOrder(Graph.java:61)
    at br.com.caelum.vraptor.interceptor.TopologicalSortedInterceptorRegistry.all(TopologicalSortedInterceptorRegistry.java:37)
    at br.com.caelum.vraptor.core.EnhancedRequestExecution.execute(EnhancedRequestExecution.java:20)
    at br.com.caelum.vraptor.VRaptor$1.insideRequest(VRaptor.java:92)
    at br.com.caelum.vraptor.ioc.guice.GuiceProvider.provideForRequest(GuiceProvider.java:76)
    at br.com.caelum.vraptor.VRaptor.doFilter(VRaptor.java:89)

Como a topologia dos interceptors não foi construída de forma correta, acontece o erro que eu mostrei no primeiro post, decorrente de uma exceção que seria lançada (Graph.java 72-74, chamada do método cycle()):

            if (roots.isEmpty()) {
                throw new IllegalStateException("There is a cycle on the interceptor sequence: \n" + cycle());
            }

Me parece que o erro é que o processo de construção de topologia dos interceptor são é thread-safe, gerando todas as exceções. Vou fazer mais uns testes aqui e se achar algo, posto aqui.
 

[Paulo Silveira - Caelum]

Oi Miguel

Excelentes observacoes.

2011/2/3 Miguel Cartagena <miguel.c...@gmail.com>:

> Me parece que o erro é que o processo de construção de topologia dos
> interceptor são é thread-safe, gerando todas as exceções. Vou fazer mais uns
> testes aqui e se achar algo, posto aqui.

O ConcurrentModificatioNException não necessariamente quer dizer que é
problema com mais de uma thread:
http://blog.caelum.com.br/concurrentmodificationexception-e-os-fail-fast-iterators/

Lucas, a ordem dos filtros é calculada em todo request? Ou apenas na
inicialização? Dependendo pode ser problema de thread safety como o
Miguel falou

Esta me parecendo um outro erro aqui:

orderTopologically chama cycle que chama removeLeaves. O removeLeaves
chama graph.remove dentro de um for que usa iterator, podendo dar o
CME.

abracos

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "caelum-vraptor" group.
> To post to this group, send email to caelum-...@googlegroups.com.
> To unsubscribe from this group, send email to
> caelum-vrapto...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/caelum-vraptor?hl=en.
>

[Lucas Cavalcanti]

só no primeiro request, mas eu não coloquei o método como synchronized =S

talvez seja bom colocar alguma guarda contra concorrência, ou mesmo fazer essa inicialização

junto com o servidor

[]'s

2011/2/3 Paulo Silveira - Caelum <paulo.s...@caelum.com.br>

[Lucas Cavalcanti]

tenta com esse snapshot, deve resolver o seu problema mais não é a melhor solução ainda

(vou trocar o synchronized por locks mais espertos)

https://oss.sonatype.org/content/repositories/snapshots/br/com/caelum/vraptor/3.3.1-SNAPSHOT/vraptor-3.3.1-20110203.133350-1.jar

Abraços

Lucas

2011/2/3 Lucas Cavalcanti <lucasm...@gmail.com>

[Miguel Cartagena]

Lucas,

Testei com o snapshot e funcionou perfeitamente. Valeu pela agilidade!

Paulo, tens razão. Uma CME pode ser lançada quando uma collection é iterada e modificada de forma errada .. eu falei que era erro de concorrência por depurando o erro não acontecia :)

Abraços

[Paulo Silveira - Caelum]

Oi Lucas e Miguel

Acho que a melhor forma é na inicializacao mesmo, em vez do primeiro
request. Assim nao precisamos nem nos preocupar com a contencao.

abracos

--
Paulo Silveira
Caelum | Ensino e Inovação
www.caelum.com.br

2011/2/3 Miguel Cartagena <miguel.c...@gmail.com>:

[Davi da Silva Nogueira]

Pessoal, também tive problema, não o mesmo.

Usando no GAE, tenho uma classe @ApplicationScoped que registra minhas classes no Objectify, e o método que registra essas classes, esta anotado com @PostConstruct, estava funcionando normalmente até eu atualizar para a versão 3.3.0. Debugando ví que essa o metodo não esta sendo chamado na inicialização da aplicação.

Esta em anexo os dois logs com o debug.

[Lucas Cavalcanti]

troca o spring pelo Guice por enquanto, Davi. Vou investigar qual é o problema.

2011/2/3 Davi da Silva Nogueira <davi...@gmail.com>

Pessoal, também tive problema, não o mesmo.

Usando no GAE, tenho uma classe @ApplicationScoped que registra minhas classes no Objectify, e o método que registra essas classes, esta anotado com @PostConstruct, estava funcionando normalmente até eu atualizar para a versão 3.3.0. Debugando ví que essa o metodo não esta sendo chamado na inicialização da aplicação.

Esta em anexo os dois logs com o debug.

--

[Davi da Silva Nogueira]

blz

[Lucas Cavalcanti]

pelo que eu vi o @PostConstruct só é chamado a primeira vez que a classe é iniciada (quando alguém pede uma instância)

vou ver se é alguma configuração do spring

2011/2/3 Lucas Cavalcanti <lucasm...@gmail.com>

[Lucas Cavalcanti]

Davi, corrigi esse bug, testa com esse snapshot por favor?

https://oss.sonatype.org/content/repositories/snapshots/br/com/caelum/vraptor/3.3.1-SNAPSHOT/vraptor-3.3.1-20110204.165640-2.jar

Miguel, eu melhorei a estratégia de sincronização do bug que vc falou, então se puder atualiza pra esse snapshot também.

Abraços

2011/2/3 Lucas Cavalcanti <lucasm...@gmail.com>

[Davi da Silva Nogueira]

Lucas, baixei esse jar, continuo fazendo meus testes, mais até agora esta OK, sem problemas.

Valeu.

[Paulo Silveira - Caelum]

Oi Lucas

Qual era o bug do PostConstruct nao ser chamado pelo spring?

--
Paulo Silveira
Caelum | Ensino e Inovação
www.caelum.com.br

2011/2/4 Lucas Cavalcanti <lucasm...@gmail.com>:

[Lucas Cavalcanti]

antes todos os PostConstructs dos AppScoped eram chamados na inicialização do servidor. Depois da refatoração

do spring isso parou de funcionar e foi lançado o 3.3.0 assim.

2011/2/4 Paulo Silveira - Caelum <paulo.s...@caelum.com.br>

[Lucas Cavalcanti]

e a causa do bug foi que a gente estava chamando um setLazyInit(true) em todo mundo, sendo que antes era só

nos componentes do VRaptor

2011/2/4 Lucas Cavalcanti <lucasm...@gmail.com>