Eu tenho a seguinte configuração no jbossmq-destinations-service.xml do JBoss:
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=Paralelo">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
Quero limitar a fila para que execute no máximo 5 mensagens simultâneas, fazendo as demais esperarem para entrar no lugar de cada uma cuja execução finalizar.
Como configuro isso?
[quote=Fox McCloud]Eu tenho a seguinte configuração no jbossmq-destinations-service.xml do JBoss:
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=Paralelo">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
Quero limitar a fila para que execute no máximo 5 mensagens simultâneas, fazendo as demais esperarem para entrar no lugar de cada uma cuja execução finalizar.
Como configuro isso?[/quote]
Numa queue não existem mensagens simultaneas, logo, não tem como configurar isso.
Tlv esteja pensando em “5 mensagens esperando dentro do queue fazem o queue não aceitar mais mensagens”
Se é isso, a pegunta seria: Porquê quer isso ?
Está certo.
O problema é que o meu onMessage() chama um EJB, então o processamento é delegado ao EJB e o papel da fila termina, só que quando a próxima mensagem entra o EJB anterior ainda está processando, e o que está acontecendo é um acúmulo de acessos simultâneos ao banco de dados, causando uma exceção por timeout na espera por uma conexão disponível ao banco… Eu teria que dar um jeito de enfileirar a próxima mensagem só quando o processamento do EJB da mensagem anterior terminasse…
Aceito sujestões!
[quote=Fox McCloud]Está certo.
O problema é que o meu onMessage() chama um EJB, então o processamento é delegado ao EJB e o papel da fila termina, só que quando a próxima mensagem entra o EJB anterior ainda está processando, e o que está acontecendo é um acúmulo de acessos simultâneos ao banco de dados, causando uma exceção por timeout na espera por uma conexão disponível ao banco… Eu teria que dar um jeito de enfileirar a próxima mensagem só quando o processamento do EJB da mensagem anterior terminasse…
Aceito sujestões![/quote]
Vc precisa do padrão Produtor-Consumidor
Coloque um BlockingQueue e adicione a mensagem nele
Crie uma Thread que lê essa queue e processa cada mensagem por vez. Isso garante que o EJB será usado de cada vez.
Por outro lado, multiplos acessos ao banco não deveriam causar problema…
Eu não devo criar uma Thread dentro do JBoss… justamente por isso estou usando JMS…
:lol: , sim, e o Coelhinho da Pascoa existe.
A sério, o que vc não deve é “Criar uma thread não gerenciada no ambiente JEE”
Mas a thread que vc cria vai estar dentro do objeto que recebe a mensagem, portanto é uma thread gerenciada, logo a regra não se aplica. Por outro lado, vc pode usar o serviço de criação de Threads do JBoss para criar a Thread. Nesse caso a regra tb não se aplica ( mas cria um vendor lock-in).
Sem saber exactamente o que está em causa é dificil de dar mais dicas. Por exemplo, que objeto é que tem o onMessage() ? É um MessageBean ?
É um MessageListener, MessageDrivenBean…
A questão é que, por regra do cliente, não posso utilizar Thread…
Aí complica, né?
:roll:
Bom, já que você citou, como eu utilizo o serviço de criação de Threads do Jboss? E o que é esse vendor lock-in?
Obrigado!
[quote=Fox McCloud]É um MessageListener, MessageDrivenBean…
A questão é que, por regra do cliente, não posso utilizar Thread…
Aí complica, né?
[/quote]
Sim, muito.
[quote]
Bom, já que você citou, como eu utilizo o serviço de criação de Threads do Jboss? E o que é esse vendor lock-in?
Obrigado!
:D[/quote]
Procure por um MBean chamado
jboss.system:service=ThreadPool
e pela interface
org.jboss.util.threadpool.ThreadPool
O uso do MBean é padrão JMX. O uso do ThreadPool é proprietário do JBoss.
O uso de funcionalidades proprietárias de um fornecedor (vendor) especifico no caso o JBoss de forma que
ao mudar para outro Application Service essas capacidades não funcionam mais é o que se chama Vendor lock-in
(tradução seria: amarrado a um fornecedor). fugir do Vendor Lockin é umas principais razões para usar o padrão JEE e portanto, usar capacidades especificas do Jboss provavelmente tb não será uma opção no seu projeto já que o cliente não quer nem depender da classe Thread que é padrão do java quanto mais de ThreadPool que não é padrão…
Está na hora de trade-off. Das duas uma, o seu cliente aceita usar thread nesse caso especifico ( afinal Produtor-Consumidor é um desing pattern) ou ele aceita o sistema como está pesando no banco.
Ou vc arranja alguma gambiarra para resolver o problema … 
:lol:
Vc pode tentar melhorar a sua implementação de uso do banco para ser mais rápida…
Boa sorte