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 28/01/2013
  • Julien Riviere
  • SOA & Urbanisation

OSB pitfalls : Timeouts HTTP

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Au même titre que pour des développements traditionnels J2EE, implémenter des services OSB nécessite d’être vigilant sur les aspects de production et d’exploitabilité. Aujourd’hui nous allons aborder un sujet classique avec Oracle Service Bus : l’exposition de services web applicatifs (ex: gestion de stock en temps réel) sur un bus de service et les précautions à prendre vis-à-vis d’un environnement de production.
Le développement de ce type de services (appelés « passe plat » car ils routent simplement les requêtes/réponses entre l’utilisateur et le service web applicatif), bien que trivial en termes d’implémentation, comporte des pièges à éviter.

Mauvaise gestion des threads du serveur d’applications : mise en place de timeouts HTTP

Par défaut un business service OSB utilisant le transport HTTP ne définit aucun timeout particulier. En l’essence, si le service web distant est très long à répondre (en cas de montée en charge par exemple) alors OSB attend indéfiniment, bloquant le thread utilisateur correspondant.
Les conséquences peuvent être désastreuses pour la production car la simple montée en charge d’un service web saturé provoque le blocage de tous les threads du serveur d’applications et l’indisponibilité des autres services OSB.
Il convient donc de positionner des gardes-fou sous la forme de timeouts HTTP. Il est possible et recommandé de positionner 2 types de timeout (voir onglet « HTTP Transport Configuration » du business service) :

  • Connection Timeout: durée maximale d’attente en seconde pour établir la connexion HTTP avec le service distant
  • Read Timeout: durée maximale d’attente en seconde pour obtenir la réponse du service distant (une fois que la requête utilisateur a été transmise)

Il ne s’agit donc ici que d’une simple configuration mais il est indispensable de l’incorporer dans vos bonnes pratiques de développement OSB.
Nous aborderons d’autres aspects de ce type dans de prochains billets « OSB pitfalls ».

Julien Riviere
Julien Riviere
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