Comme la majorité des bus d’entreprise, Oracle Service Bus (OSB) est capable de faire du « throttling », il peut contrôler le nombre de requête à envoyer vers un service cible. Ce besoin est récurrent car de nombreux systèmes ne peuvent suivre la cadence d’envoi d’OSB.
Si on ne prend pas en compte le throttling, le risque de saturation est important car une fois la capacité de réception du système atteint, les performances se dégradent et dans le pire des cas, provoquer un arrêt brutal du système cible !
Intéressé ? Lisez la suite !
Dans cet article, nous allons aborder deux méthodes de mise en place du throttling pour OSB :
- La première méthode consiste à limiter le nombre de requête transmise par un business service (outbound throttling)
- La seconde méthode consiste à limiter le nombre de thread qui traite une requête entrante (inbound throttling)
Outbound throttling
Le paramétrage se fait au niveau de la console OSB et non pas à la création du business service.
Cependant et sauf en cas de modification de nom ou de place du business service, la republication du business service depuis Eclipse ne supprimera pas le paramétrage.
Dans la console OSB :
Maximum concurrency : nombre de messages que le business service traite en concurrence. Lorsque ce maximum est atteint, les messages sont placés dans la throttling queue.
Throttling Queue : taille maximale de la throttling queue. Lorsque la queue est pleine, le message de plus faible priorité sera remplacé par un nouveau message de plus forte priorité. C’est une file en mémoire et donc ne supporte pas le fail-over (pas de récupération possible en cas de crash).
Message Expiration : restreint le temps passé par un message dans la throttling queue.
Inbound throttling
Cette méthode consiste à créer un work manager dans Weblogic afin de limiter le nombre de requête concurrente traiter par un proxy service (Dispatch Policy).
Création du Work Manager
Dans la console Weblogic :
Création des contraintes
Cliquez sur le work manager nouvellement créé et toujours en mode édition :
Créez une nouvelle contrainte de type Maximum Thread Constraint en cliquant sur New
Nommez votre contrainte et positionnez le paramètre count qui représente le nombre de messages qui sera traité en concurrence, puis cliquez sur Next. Choisissez une cible, cliquez sur Finish, activez les changements.
Paramétrage du proxy service
La dernière étape consiste à associer le work manager au proxy service, afin de restreindre le nombre de requêtes traitées :
Localisez votre proxy service et cliquez dessus. Editez la partie JMS Transport Configuration |
Choisissez le work manager pour le paramètreDispatch Policy. Cliquez sur last, puis finish, et activez les changements. |
4 réflexions sur “Oracle Service Bus throttling”
Bonjour, je suis dans la configuration suivante:
————————————————————————————————
file MQ -> PROXY (protocol JMS) -> BUSINESS (protocol JMS) -> file MQ
————————————————————————————————
Mon proxy lit donc sur une file MQ, route le message vers un business qui publie sur une seconde file MQ.
Afin de diminuer le nombre de connexions vers mon MQ manager, j’ai ajouté un un work manager avec un ‘maximum threads constraint’ sur mon proxy, ce qui semble fonctionner.
Par contre, j’ai également ajouté le paramètrage de throttling sur mon business afin de limiter le nombre de connexions établies vers le work manager en sortie, ce qui n’a aucun effet 🙁 .
Je voulais donc savoir si le throttling est prévu pour fonctionner avec les files MQ ? Si ce n’est pas le cas, existe-t-il un autre moyen de limiter le nombre de connexions vers mon Qmanager en sortie de mon flux?
Merci d’avance.
@GB
Pour limiter le nombre de messages en sortie, il faut suivre le paramétrage de la partie « Outbound Throttling », c’est à dire configurer le business service directement dans la partie « Operationnal settings » de la console OSB.
Faites le test et tenez moi au courant 🙂
B.
Oui, lorsque la valeur maximale de la contrainte est atteinte, les messages sont déposés dans une
file appelée « la Throttling Queue » qui est une file en mémoire
Merci pour cette article très intéressant 🙂
Petite question sur le Workmanager : que fait il des requêtes en attente en cas d’écrasement, une file JMS ? en mémoire ?
D’avance merci,
Jérôme
Les commentaires sont fermés.