2 <name>message-driven-bean</name> 3 <invoker-mbean>default</invoker-mbean> 4 <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy- factory> 5 <proxy-factory-config> 6 <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI> 7 <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFacto- ryJNDI> 8 <CreateJBossMQDestination>true</CreateJBossMQDestination>
9 <!-- WARN: Don't set this to zero until a bug in the pooled execu-
tor is fixed --> 10 <MinimumSize>1</MinimumSize> 11 <MaximumSize>15</MaximumSize> 12 <KeepAliveMillis>30000</KeepAliveMillis> 13 <MaxMessages>1</MaxMessages> 14 <MDBConfig> 15 <ReconnectIntervalSec>10</ReconnectIntervalSec> 16 <DLQConfig> 17 <DestinationQueue>queue/DLQ</DestinationQueue> 18 <MaxTimesRedelivered>10</MaxTimesRedelivered> 19 <TimeToLive>0</TimeToLive> 20 </DLQConfig> 21 </MDBConfig> 22 </proxy-factory-config> 23 </invoker-proxy-binding>
Os elementos <JMSProviderAdapterJNDI> e <ServerSessionPoolFactoryJN- DI> fazem a ligação do MBD ao servidor MOM que hospeda a fila de mensa- gens. Eles apontam respectivamente para componentes JMSProviderAdapter e ServerSessionPoolFactory que são fornecidos pelo cliente JMS do próprio MOM.
A implementação destes dois componentes pelo JBoss MQ é inicializada e pu- blicada no diretório do servidor de aplicações pelos MBeans JMSProvider- Loader e ServerSessionPoolMBean, ambos definidos em deploy/jms/jms-d- s.xml, junto com as fábricas de conexões JCA que devem ser utilizadas por
Servlets e EJBs para publicação e consumo de mensagens em filas deste mesmo MOM.
As configurações do provedor JMS para acesso a um MOM serão vistas em mais detalhes no próximo capítulo, quando entraremos em maiores detalhes da configuração do JBoss MQ e sua integração com o JBoss AS.
6.3.2.
Recebimento (consumo) concorrente de mensagens
Do mesmo modo que é possível ter vários clientes chamando ao mesmo tempo um EJB, e o servidor de aplicações irá alocar threads para processar estas chamadas em paralelo, é possível configurar o servidor de aplicações para alo- car várias threads para receber mensagens de uma mesma fila e repassá-las para um MDB.Só que no caso de um MDB não existe um MBean Invocador responsável pelo recebimento de requisições remotas para um MBD. Afinal, componentes de aplicação não chamam um MDB. É o próprio MBD quem responde à presença de mensagens pendentes em uma fila.
Por isso a configuração de threads para o recebimento de mensagens e execu- ção do MDB fica na própria configuração de invocador do MDB, em vez de na configuração do MBean Invocador do JBoss AS – não existem MBeans Invoca- dores vinculados a um MDB!
Reveja a Listagem 6.4 e note os atributos <MinimumSize> e <MaxSize>. Eles determinam os limites para um pool de threads exclusivo para o MDB. Ou se- jam cada MBD recebe seu próprio pool de threads, e todos os MDBs recebe- rão pools com o mesmo tamanho, a não ser que as suas configurações de invo- cador sejam customizadas.
Já o atributo <MaxMessages> pode ser usado para provocar um “acúmulo” de mensagens na fila. Ele indica quantas mensagens terão que se acumular antes que se inicie o consumo delas pelo MDB.
Este acúmulo pode gerar uma melhor performance geral no processamento de mensagens, pois maximiza a probabilidade de um MDB processar várias men- sagens em uma mesma fatia de tempo do processador, em vez de disparar vá- rios threads de processamento concorrentes, que logo ficarão ociosos por falta de trabalho (mensagens) para ser realizado.
Caso vários MDBs sejam configurados para consumir do mesmo Queue, não haverá distribuição das mensagens entre estes MDBs. Afinal, uma fila não está preocupada com quem vai consumir suas mensagens, e se uma mensa- gem sera consumida uma única vez, por um único consumidor, não importa para ela quem é este consumidor. Então, conceitualmente falando, não deveri- am existir vários MDBs vinculados ao mesmo Queue!
Da mesma forma, caso existam várias instâncias e threads em um mesmo MDB, não importa qual instância consome cada mensagens, afinal MDBs são
19 Note que o MDB não utilizará a fábrica de conexões JCA. Esta sim utilizará o JMSProviderAdapter e o ServerSessionPoolFactory.
6.3. Configuração de MDBs
stateless. Não haverá “distribuição de carga” entre as instâncias, na verdade não haver esta preocupação reduz o overhead de processamento sem afetar o resultado final.
6.3.3.
MDBs Singleton
A configuração de fábrica do JBoss AS gera consumo em paralelo de mensa- gens por um MDB, o que aumenta o throughput das aplicações, mas também pode acabar gerando processamento de mensagens fora de origem. Isto signi- fica que mensagens inseridas na fila antes podem acabar tendo seu processa- mento finalizado apenas depois de mensagens que haviam sido inseridas pos- teriormente.
Máquinas virtuais Java e SOs típicos não são sistemas determinísticos, tam- bém chamados de sistemas de tempo-real20. de modo que o paralelismo no
processamento de mensagens pelas várias instâncias e threads pode provocar este comportamento. Especialmente se o tempo de processamento de uma mensagem for bem diferente de outra mensagem, dependendo do conteúdo em cada uma.
Para a maioria das aplicações realmente não faz diferença se as mensagens fo- ram processadas na ordem de recebimento ou não, então uma fila JMS não tem o comportamento FIFO21. Algumas aplicações podem entretanto exigir a
ordenação estrita no processamento das mensagens, e a obediência à ordem de chegada.
Para estes casos, o JBoss AS já fornece a configuração de container Singleton Message Driven Bean. A única diferença entre ela e configuração default apresentada na listagem 6.3. é a referência a uma configuração de invoca- ção que limita a quantidade de threads concorrentes em no máximo uma.
6.3.4.
O Dead Letter Queue
Outra configuração importante de invocador de um MDB é o DLQ, ou Dead
Letter Queue. A configuração padrão em standardjboss.xml, exibida na Listagem 6.4 aponta para a fila pré-definida queue/DLQ.
A função do DLQ é evitar que uma mensagem com conteúdo mal-formatado “engasgue” a fila, provocando continuamente erros de execução no MDB.
Se uma mesma mensagem for consumida sem sucesso por mais do que <Max- TimesRedelivered>, ela é transferida para a fila <DestinationQueue>, onde é possível examinar o conteúdo da mensagem e até mesmo iniciar algum pro- cesso manual para corrigir seu conteúdo e encaminhá-la de volta para a fila original.
20 Ao contrário do que muitos imaginam, sistemas de “tempo real” não tem nada a ver com sistemas interativos ou “on line”. O “tempo real” está ligado ao fato de que a duração e ordenação dos eventos é previsível dentro de limites rigidamente determinados, e não tem nada a ver com este processamento ser síncrono ou assíncrono, ou com ele ser interativo ou em retaguarda.
21 Fitst-In, First-Out. O primeiro a entrar é o primeiro a sair.
Listagem 6.5 – Configuração de invocador para MDB limitando a quantidade de