TOC

Estratégias simultâneas usando MDBs

Estratégias simultâneas usando MDBs

1. Introdução

O Message Driven Beans, também conhecido como "MDB", manipula o processamento de mensagens em um contexto assíncrono. Podemos aprender o básico do MDB emthis article.

Este tutorial discutirá algumas estratégias e práticas recomendadas para implementar a simultaneidade usando o Message Driven Beans.

Se quiser entender mais sobre os fundamentos da simultaneidade usando Java, você pode começarhere.

Para usar melhor os MDBs e a simultaneidade, há algumas considerações a serem feitas. It’s important to keep in mind that those considerations should be driven by the business rules and the needs of our application.

2. Ajustando o Thread Pool

Ajustar o pool de threads é provavelmente o principal ponto de atenção. Para fazer um bom uso da simultaneidade, devemostune the number of MDB instances available to consume messages. Quando uma instância está ocupada manipulando uma mensagem, outras instâncias podem capturar as próximas.

A threadMessageListener é responsável por executar o métodoonMessage de um MDB. Este encadeamento faz parte do pool de encadeamentosMessageListener, o que significa que ele é agrupado e reutilizado continuamente. This pool also has a configuration that allows us to set the number of threads, which may impact the performance:

  • definir um tamanho de pool pequeno fará com que as mensagens sejam consumidas lentamente ("Otimização do MDB")

  • definir um tamanho de pool muito grande pode diminuir o desempenho - ou nem funcionar.

EmWildfly, podemos definir esse valor acessando o console de gerenciamento. O recurso JMS não está ativado no perfil autônomo padrão; precisamos iniciar o servidor usandofull profile.

Normalmente, em uma instalação local, acessamos através dehttp://127.0.0.1:9990/console/index.html. Depois disso, precisamos acessar Configuration / Subsystems / Messaging / Server, selecione nosso servidor e clique em "View".

Escolha a guia "Atributos", clique em "Editar" e altere o valor de "Tamanho máximo do conjunto de threads". O valor padrão é 30.

3. Ajuste de sessões máximas

Outra propriedade configurável a ser observada éMaximum Sessions. Isso define a simultaneidade para uma porta de ouvinte específica. Geralmente, esse padrão é 1, mas aumentá-lo pode oferecer mais escalabilidade e disponibilidade ao aplicativo MDB.

Podemos configurá-lo por anotações ou descritores.xml. Por meio de anotações, usamos o@ActivationConfigProperty: 

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName=”maxSession”, propertyValue=”50”
    )
})

Se o método de configuração escolhido forem os descritores.xml, podemos configurarmaxSession assim: 


    
        maxSession
        50

4. Ambiente de implantação

Quando temos um requisito de alta disponibilidade, devemos considerar a implantação do MDB em um cluster de servidores de aplicativos. Portanto, ele pode ser executado em qualquer servidor do cluster e muitos servidores de aplicativos podem invocá-lo simultaneamente, o que também melhora a escalabilidade.

Para este caso em particular, temos uma escolha importante a fazer:

  • makeall servers in the cluster eligible to receive messages, que permite o uso de todo o seu poder de processamento, ou

  • garanta o processamento da mensagem emsequential manner by allowing just one server to receivethem at a time

Se usarmos um barramento corporativo, uma boa prática é implantar o MDB no mesmo servidor ou cluster que o membro do barramento para otimizar o desempenho do sistema de mensagens.

5. Modelo de mensagem e tipos de mensagem

Embora isso não seja tão claro quanto apenas definir outro valor para um pool, o modelo de mensagem e o tipo de mensagem podem afetar uma das melhores vantagens do uso de simultaneidade: desempenho.

Ao escolher XML para um tipo de mensagem, por exemplo,the size of the message can affect the time spent to process it. Essa é uma consideração importante, especialmente se o aplicativo manipular um grande número de mensagens.

Em relação ao modelo de mensagem,if the application needs to send the same message to a lot of consumers, a publish-subscribe model might be the right choice. Isso reduziria a sobrecarga de processamento das mensagens, proporcionando melhor desempenho.

Para consumir de aTopic em um modelo publicar-assinar, podemos usar anotações: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Topic")

Novamente, também podemos configurar esses valores em um descritor de implantação.xml: 


    
        destinationType
        javax.jms.Topic

Se o envio da mesma mensagem para muitos consumidores não for um requisito, o modelo PTP (Ponto a Ponto) regular seria suficiente.

Para consumir de uma fila, definimos a anotação como: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Queue")

Se estivermos usando o descritor de implantação.xml, podemos defini-lo: 


    
        destinationType
        javax.jms.Queue

6. Conclusão

Como muitos cientistas da computação e escritores de TI já declararam, não temos mais a velocidade dos processadores aumentando em ritmo acelerado. Para tornar nossos programas mais rápidos, precisamos trabalhar com o maior número de processadores e núcleos disponíveis atualmente.

Este artigo discutiu algumas práticas recomendadas para aproveitar ao máximo a simultaneidade usando MDBs.

Related