Pessoal, estou com um problema num MDB rodando no JBoss 3.2.3
O MDB roda numa transação gerenciada pelo bean, faz o registro da solicitação no bd, faz o commit desta transação. Depois o mdb chama um session bean que também utiliza uma transação gerenciada pelo bean e aguarda este processamento terminar. Este processamento é executado dentro de uma transação que é controlada pelo session bean, que também é bmt. Após retornar da chamada ao session bean, o mdb inicializa outra transação para gravar no banco o status de processamento retornado pelo mdb. Estou seguindo todas as recomendações da especificação. O ejb mdb não lança nenhum erro e as transações são sempre finalizadas ou é feito um rollback caso ocorra algum erro.
Desta forma, segundo a especificação, a mensagem não deveria ser reenviada ao mdb, mesmo porque a transação que faz o controle do recebimento da mensagem é independente da UserTransaction utilizada dentro do método onMessage no caso de mdbs com transação gerenciada pelo bean.
Mas o estranho é que as mensagens são reenviadas novamente ao mdb.
Já procurei nos fóruns do JBoss porém não encontrei nada que me ajude.
Sei que após o número máximo de reenvios configurado no jboss a msg é consumida pelo dlq, e no meu caso o processamento da mensagem repetidas vezes não é um problema, mas é ruim este comportamento, pois vai contra o que está escrito na especificação e ocasiona um problema sério de performance.
Alguém já passou por isso ou tem alguma sugestão?
Agradeço quem puder me ajudar.
Até mais.
Problemas com MDB no JBoss
1 Resposta
Após fazer um debug no source do jboss, na classe onde um dos problemas ocorria, descobri duas coisas. A transação que o Container inicia para o processamento da mensagem é diferente da UserTransaction que utilizo no meu método (como manda a especificação), porém o seu timeout desta transação é definido pelo jboss e é diferente do timeout que coloco na UserTransaction, e parece que este timeout não é atualizado quando atualizo o timeout no objeto UserTransaction. Desta forma o servidor faz um rollback desta transação antes da minha terminar e é por isso que a mensagem é reenviada. Neste caso consegui resolver de forma programática. Como o processamento grava uma solicitação no banco, passei a verificar o status para saber se o processamento já foi realizado. Isto não eliminou o problema completamente, a mensagem é reenviada ao mdb ainda, porém na segunda vez o método não faz nada, pois verifica o status de processamento, que já foi realizado durante a primeira entrega da mensagem. Desta forma o método é executado rapidamente e a transação que controla a entrega da mensagem é confirmada. Isto elimina o problema no meu caso, porém não sei se existe uma forma de configurar o timeout para esta transação utilizada pelo Container.
Após resolver este problema me deparei com outro, com um motivo também relacionado a um timeout. Como algumas das transações executadas pelo SessionBean que é chamado pelo MDB são longas, a Thread que controla o processamento é colocada no estado “interrupted”, como pude observar ao debugar o código do jboss. Este timeout também não respeita o timeout que configuro no meu objeto UserTransaction. Desta forma, quando o servidor coloca a thread neste estado, qualquer chamada a algum método que necessite de algum recurso do servidor (um lookup, uma abertura de conexão com o bd através de um datasource, etc) após a thread ser colocada no estado “interrupted” gera um erro com a mensagem “Interrupted while request Permit!”. No meu código coloquei então em alguns pontos a instrução Thread.interrupted() para fazer a trhead sair do estado “interrupted” e desta forma tudo passou a funcionar corretamente. Não sei se estes problemas que encontrei debugando as classes do jboss são bugs já corrigidos numa versão mais nova do servidor, porém achei bom postar como resolvi estes problemas para ajudar outras pessoas no caso de alguém também encontrá-los, pois, como disse anteriormente, não consegui encontrar nenhuma solução nos fóruns que procurei, apenas perguntas com casos em que os “sintomas” do problema eram parecidos com os que ocorreram comigo.
Valew, pessoal, até mais.