mercredi 17 juillet 2013
 
Pour OSB, la gestion de thread dépend des artefacts déployés. Par nature, le Proxy/Business Service fonctionne avec des threads séparés (Inbound/Outbound Request Message Thread) pour dissocier le traitement de la requête de la réponse.
 
 
Dans certains cas la requête attend la réponse (même thread d’exécution). L’exécution sur un seul thread peut provenir :
 
  • D’un transport bloquant (blocking transport).
  • D’un Proxy faisant partie d’une transaction globale.
 
Transports Bloquant
 
 
Dans le cas de Proxy/Business Service, vous pouvez déclarer un WorkManager spécifique et côté Business Service vous pouvez utiliser le Throttling (mécanisme de file mémoire de régulation).
 
Le Proxy Service et Business service (ou Nested Proxy) s’exécute dans le même thread d’exécution, et l’association d’un WorkManager associé à un Proxy ou Business correspond a une affectation sur le thread request ou response côté Inbound ou Outbound (a l’extérieure d’OSB). Le throtlling lui s’applique en interne d’OSB (thread activé).
 
(dans le cas d’un Business Service, le WorkManager ne s’applique que sur la reponse)
 
Dans le cas du WorkManager, pour remonter une erreur dans le cas d’empilement d’appels en blocage externe, vous pouvez utiliser une contrainte. Dans le cas du throttling, l’expiration des requêtes entraine une erreur côté client. Vous pouvez également mettre en place une désactivation automatique des artefacts selon un SLA comme présentée dans ce blog (non-natif au produit) :
 
INBOUND

 
Au sein des messages flow des Proxy Service, vous pouvez définir des appels de service de façons différentes impliquant une gestion de thread particulière pour chaque cas.
 
  • Publish invocation asynchrone (one way) sans attendre la réponse dans le message flow.
  • Callout Invocation multiple synchrone de service dans le message flow.
  • Routing Invocation synchrone ou asynchrone d’un simple business Service en fin de message flow.
 
 
La gestion des threads est utilisée différemment selon les cas sachant que le mode Publish est asynchrone est donc n’attend pas de notification retour du service distant.
 
ROUTING
 
Dans le cas du Routing synchrone (ou publish synchone avec QoS=ExactlyOnce), ce n’est pas un seul thread, mais deux (Request/Response en thread dissocié) qui supporte l’activation du message flow (sauf dans le cas d’une transaction globale déclarée côté client (XAConnectionFactory) et le Proxy en transaction (QoS=ExactlyOnce).
 
La notification retour est déclenchée via le Muxer Weblogic (WLS AsyncResponseHandler callback) qui active un autre thread sur le message flow retour du Proxy Service. De cette façon, le thread Request ne reste pas bloqué sur l’attente de la réponse retour.
 
CALLOUT
 
Dans le cas du Callout, la requête synchrone (Request/Response) est gérée par un seul thread, mais le retour est déclenché par un autre thread de notification activé par le même mécanisme Muxer que le Routing. Il y a donc toujours 2 threads utilisés, mais le Callout n’est supporté que par un seul Thread.
 
PROXY CHAINING
 
Dans le cas où un Proxy Service appel un autre Proxy Service, l’ensemble de l’appel s’exécute sur un même thread d’exécution (Thread Request/Thread Response).
 
WORKMANAGER
 
OSB permet d’associer un WorkManager à un Proxy et Business Service. L’intérêt étant de modifier les contraintes pour déclarer un minimum de thread afin d’éviter les inters blocage lié au mode de threading de l’appel ou un maximum afin d’éviter des saturations de service. On pourrait ainsi définir certains cas d’usage ou règles à appliquer lors de constatations de contention:
 
  • Définir un MinThreadConstraint à 3 ou 5 thread sur un Proxy Service dans le cas où l’on a plusieurs Callout afin de ne pas attendre sur le thread de notification. Même remarque entre inter appel de Proxy Service sur une même instance Weblogic.
  • On pourra utiliser un MaxThreadConstraint pour tuner un Proxy type MDB afin de gérer le throughput de dépilement ou borner les appels d’un service impliqué dans le Proxy.
  • Eviter d’utiliser un même WorkManager pour un Proxy Service et un Business Service dépendant (inter blocage).
 
OUTBOUND

 
Les Outbound (appels sortants) peuvent être régulés par le WorkManager mais également par un mécanisme de file mémoire interne à OSB (Throttling). On pourra dans ce cas définir pour chaque Business une contrainte de requêtage request spécifique.
 
L’intérêt étant de ne pas devoir déclaré autant de WorkManager et de contrainte Max que de Proxy sachant que les contraintes étant globales et que l’affectation d’un WorkManager sur les flux sortants s’applique sur les Proxy (responsable des thread request).

0 commentaires:

AUTEUR

Ma photo
Carrières Sur Sein, Yvelines, France
Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV

LABEL 3D

Blogumulus by Roy Tanck and Amanda Fazani

LABEL CLOUD

MAP

Locations of visitors to this page

AUTRES BLOG

LIVRES

MEMBRES