Aller au contenu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Menu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Blog

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 29/10/2014
  • Sebastien Antony
  • Développement, Java, Page d'accueil, Serveurs d'application

Uniform Distributed Queue et Forward Delay

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Bien souvent lorsque l’on souhaite consommer une file JMS, on se retrouve dans un cas simple, où finalement nos consommateurs sont de type MDB. Sur nos serveurs, on se préoccupe peu que cela fonctionne dans les détails, ils se connectent et consomment.
Mais qu’arrive-t-il si l’on se place dans un environnement cluster et que les consommateurs ne sont plus forcément sur notre plateforme ? Voici un cas tout simple : Notre consommateur fonctionne en mode batch et ne présente pas forcément autant de consommateurs que de nœuds de notre cluster. Voyons une solution envisageable…


Présentation du cas

Concrètement vous avez un environnement cluster, et voudriez en conséquent, pouvoir utiliser les files JMS distribuées. Ceci fonctionnera très bien en temps normal : nos consommateurs mettront en place plusieurs consommateurs et se répartiront sur les nœuds du cluster. Les éléments gérés seront envoyés et consommés là où cela est possible.
Les Uniform Distributed Queues vont être de manière générale :

  • Disponibles sur tous les nœuds du cluster
  • Leurs messages seront consommés au fil de l’eau
  • Leurs messages seront mis à disposition en priorité sur les nœuds avec consommateurs
  • Attaquées par des consommateurs qui se répartiront sur les noeuds

Mais finalement un des consommateurs sera en mode batch, avec un unique consommateur. Pour un tel cas on ne souhaiterait pas remettre en cause le reste. L’idéal est donc de trouver un paramétrage qui pourrait permettre de solutionner ce cas.

Forward Delay

Ce paramétrage est à mettre en place sur une file JMS. Il aura pour but de mettre en place un délai d’attente, en secondes, avant transfert des messages vers un autre membre qui lui aurait des consommateurs présents.
Par défaut cet attribut de notre Uniform Distributed Queue est mis à la valeur -1, ce qui signifie qu’aucun délai n’est mis en place pour effectuer ce transfert.
Grâce à cette option, on va activer ce délai, et préciser par exemple que les messages doivent être redirigés après 5s.
A présent, notre consommateur unique sera en capacité de recevoir tous les messages présents sur tous les nœuds du cluster. Pour cela il devra uniquement rester présent un certain délai pour permettre au message d’être redirigés vers son nœud.

Conclusion

Ceci ne présente qu’un petit paramétrage JMS, il en existe bien d’autres : redirection d’erreur, paramétrage des quotas… … comme celui présenté ici certains peuvent avoir un intérêt important.
Pour gérer notre cas nous avons opté pour une solution simple, qui permettra de contourner un certain nombre de cas, sans sacrifier de haute disponibilité. D’autres options auraient pu être envisagées : store and forward, cibles migrables… plus complexes à appréhender, mais qui répondront à d’autres problématiques également !

Sebastien Antony
Sebastien Antony
Voir tous ses articles

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles récents
  • Azure Database pour PostgreSQL [PaaS]
  • Azure Logic Apps : l’outil d’intégration Cloud de Microsoft
  • Purge automatique des archivelogs en PL/SQL
  • ASM et l’importance du usable_file_mb
  • Préparer un Windows Server 2003 pour une migration sur Azure

Mentions légales & Politique de confidentialité

En poursuivant votre navigation, vous acceptez l'utilisation de cookies tiers destinés à réaliser des statistiques de visites et de suivi. Accepter Refuser Personnaliser En savoir plus
Politique de confidentialité et cookies

Politique de confidentialité

Les informations collectées au travers de nos cookies sont exploitées à des fins statistiques (Google Analytics).
Google Analytics
Enregistrer & appliquer

8 JUIN 2022 A PARIS | 8H30 - 18H30

TECH FOR CLIMATE ?

Opportunités et limites de la technologie pour faire face au défi climatique

Programme & Inscriptions

Un évènement imaginé avec 🖤 par Constellation