TOC

Stratégies concurrentes utilisant les BMD

Stratégies concurrentes utilisant les BMD

1. introduction

Message Driven Beans, également appelé «MDB», gère le traitement des messages dans un contexte asynchrone. Nous pouvons apprendre les bases de MDB enthis article.

Ce tutoriel présentera certaines stratégies et meilleures pratiques pour implémenter la simultanéité à l'aide de Message Driven Beans.

Si vous souhaitez en savoir plus sur les bases de l'accès concurrentiel à l'aide de Java, vous pouvez commencerhere.

Afin de mieux utiliser les MDB et la simultanéité, certaines considérations doivent être prises en compte. It’s important to keep in mind that those considerations should be driven by the business rules and the needs of our application.

2. Réglage du pool de threads

Le réglage du pool de threads est probablement le principal point d’attention. Pour faire un bon usage de la concurrence, nous devonstune the number of MDB instances available to consume messages. Lorsqu'une instance est occupée à traiter un message, d'autres instances peuvent récupérer les suivantes.

Le threadMessageListener est chargé d'exécuter la méthodeonMessage d'un MDB. Ce thread fait partie du pool de threads deMessageListener, ce qui signifie qu'il est mis en commun et réutilisé encore et encore. This pool also has a configuration that allows us to set the number of threads, which may impact the performance:

  • Si vous définissez une petite taille de pool, les messages seront consommés lentement («MDB Throttling»).

  • définir une taille de pool très importante peut réduire les performances - voire ne pas fonctionner du tout.

SurWildfly, nous pouvons définir cette valeur en accédant à la console de gestion. La fonctionnalité JMS n'est pas activée sur le profil autonome par défaut; nous devons démarrer le serveur en utilisant lesfull profile.

Habituellement, sur une installation locale, nous y accédons viahttp://127.0.0.1:9990/console/index.html. Après cela, nous devons accéder à Configuration / Sous-systèmes / Messagerie / Serveur, sélectionnez notre serveur et cliquez sur «Afficher».

Choisissez l'onglet «Attributs», cliquez sur «Modifier» et modifiez la valeur de «Taille maximale du pool de threads». La valeur par défaut est 30.

3. Réglage des sessions maximum

Une autre propriété configurable à connaître estMaximum Sessions. Ceci définit la simultanéité pour un port d'écoute particulier. La valeur par défaut est 1, mais son augmentation peut donner davantage d’évolutivité et de disponibilité à l’application MDB.

Nous pouvons le configurer soit par des annotations, soit par des descripteurs.xml. Grâce aux annotations, nous utilisons les@ActivationConfigProperty: 

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

Si la méthode de configuration choisie est les descripteurs.xml, nous pouvons configurermaxSession comme ceci: 


    
        maxSession
        50

4. Environnement de déploiement

Lorsque nous avons besoin de haute disponibilité, nous devrions envisager de déployer la MDB sur un cluster de serveurs d'applications. Ainsi, il peut s'exécuter sur n'importe lequel des serveurs du cluster et de nombreux serveurs d'applications peuvent l'invoquer simultanément, ce qui améliore également l'évolutivité.

Pour ce cas particulier, nous avons un choix important à faire:

  • makeall servers in the cluster eligible to receive messages, qui permet d'utiliser toute sa puissance de traitement, ou

  • assurer le traitement des messages dans unsequential manner by allowing just one server to receivethem at a time

Si nous utilisons un bus d'entreprise, il est conseillé de déployer la MDB sur le même serveur ou le même cluster que le membre du bus afin d'optimiser les performances de la messagerie.

5. Modèle de message et types de message

Bien que ce ne soit pas aussi clair que de simplement définir une autre valeur pour un pool, le modèle de message et le type de message peuvent affecter l'un des meilleurs avantages de l'utilisation de la concurrence: les performances.

Lorsque vous choisissez XML pour un type de message, par exemple,the size of the message can affect the time spent to process it. C'est une considération importante, surtout si l'application gère un grand nombre de messages.

Concernant le modèle de message,if the application needs to send the same message to a lot of consumers, a publish-subscribe model might be the right choice. Cela réduirait les frais généraux liés au traitement des messages et améliorerait les performances.

Pour consommer à partir d'unTopic sur un modèle de publication-abonnement, nous pouvons utiliser des annotations: 

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

Encore une fois, nous pouvons également configurer ces valeurs dans un descripteur de déploiement.xml: 


    
        destinationType
        javax.jms.Topic

Si l’envoi du même message à de nombreux consommateurs n’est pas obligatoire, le modèle PTP (point à point) classique suffira.

Pour utiliser une file d'attente, nous définissons l'annotation comme suit: 

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

Si nous utilisons le descripteur de déploiement de.xml, nous pouvons le définir: 


    
        destinationType
        javax.jms.Queue

6. Conclusion

Comme l'ont déjà mentionné de nombreux informaticiens et rédacteurs informatiques, la vitesse des processeurs ne s'accélère pas rapidement. Pour que nos programmes fonctionnent plus rapidement, nous devons travailler avec le plus grand nombre de processeurs et de cœurs disponibles aujourd'hui.

Cet article présente certaines des meilleures pratiques pour tirer le meilleur parti de la concurrence en utilisant des bases de données multi-supports

Related