[z/OS]

Présentation des horloges

Les horloges définissent un délai requis pour l'exécution d'une opération. Le type d'opération contrôlé par une horloge détermine à quel moment la période définie par cette horloge commence à s'écouler.

Propriétés de compteur relatives à la configuration des beans gérés par message pour utiliser des ports d'écoute ou des spécifications d'activation

Les ports d'écoute sont obsolètes à partir de la version 7 et des versions ultérieures de WebSphere Application Server. Therefore you should plan to migrate your IBM MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. In some cases you will continue to use the IBM MQ message-driven bean deployment and listener ports and in other case you will use the IBM MQ message-driven bean deployment and activation specifications.

Les propriétés suivantes NE s'appliquent PAS au déploiement de bean géré par message piloté par la spécification d'activation. That is, the properties require you to configure them to use the IBM MQ message-driven bean deployment and listener ports:
  • control_region_mdb_request_timeout
  • control_region_mdb_queue_timeout_percent
  • server_region_mdb_stalled_thread_dump_action
Les propriétés suivantes NE s'appliquent PAS au déploiement de bean géré par message piloté par la spécification d'activation. That is, these properties require you to configure them to use the IBM MQ message-driven bean deployment and activation specifications.
  • control_region_wlm_dispatch_timeout
  • control_region_iiop_queue_timeout_percent
  • server_region_iiop_stalled_thread_dump_action

Lorsque vous suivez les instructions de configuration de ces propriétés, gardez en mémoire les propriétés qui s'appliquent aux ports d'écoute par rapport à celles qui s'appliquent aux spécifications d'activation.

La plupart des horloges ont une valeur par défaut qui définit une période de temps raisonnable pendant laquelle une opération particulière doit être exécutée. Une fois que la limite indiquée pour l'horloge s'est écoulée, le produit effectue une des opérations suivantes :
  • Il envoie un code mineur au client si la limite de temps s'écoule avant que la demande du client ne soit envoyée à un servant.
  • Il arrête anormalement le servant avec un code EC3 ABEND si la limite de temps s'écoule pendant que la demande du client est traitée par un composant d'application qui s'exécute dans le servant.

    Dans cette situation, toutes les unités d'exécution de ce servant prennent fin. Le servant prend également fin pour empêcher l'application de mettre en attente des ressources et donc pour éviter que les autres demandes utilisent ces ressources. Une fois le servant arrêté, WLM lance un nouveau servant prenant la place du servant arrêté.

    Eviter les incidents Eviter les incidents: Le délai de la durée de vie totale de la transaction et le délai d'expiration maximal de la transaction possèdent des périodes de grâce au-delà de la valeur d'expiration spécifiée d'environ quatre minutes. Ce délai doit s'écouler avant qu'un ABEND se produise. gotcha
Des types différents d'horloges peuvent atteindre leurs limites de temps simultanément, car les opérations qu'elles contrôlent peuvent se chevaucher jusqu'à un certain point. Par exemple, supposons que le serveur d'applications reçoive une requête client IIOP qui est traitée par un composant d'application utilisant un support de transactions. Dans ce cas, les deux horloges suivantes comptent à rebours simultanément :
  • control_region_wlm_dispatch_timeout, qui limite à la fois la durée pendant laquelle une requête client attend dans la file d'attente WLM, ainsi que la durée nécessaire au composant d'application pour traiter la requête
  • transaction_defaultTimeout, qui limite la durée pendant laquelle le contrôleur attend la validation ou l'annulation d'une transaction

Ces horloges se chevauchent uniquement pendant la durée de traitement de la transaction. Pour savoir quelle horloge provoque l'incident, vous pouvez utiliser les codes mineurs spécifiques aux symptômes ou les codes anomalie d'arrêt anormal EC3.

Pour déterminer l'occurrence d'un délai aussi vite que possible et pour éviter d'autres verrouillages de ressources, WebSphere Application Server empêche d'autres travaux de transaction sur le chemin de transaction où la condition de délai a eu lieu. Cela s'applique de la même manière à la tentative d'exécution de travail dans le contexte de transaction en cours et à la tentative d'exécution de travail dans un contexte transactionnel différent.

Les horloges servant à contrôler le comportement du traitement peuvent être classées en cinq type généraux. Ces derniers, ainsi que les opérations qu'ils contrôlent, sont récapitulés dans le tableau ci-dessous.

Tableau 1. Récapitulatif des types généraux. Les horloges servant à contrôler le comportement du traitement peuvent être classées en cinq type généraux. Ces derniers, ainsi que les opérations qu'ils contrôlent, sont récapitulés dans le tableau ci-dessous.
Type général Traitement de l'horloge Symptômes d'expiration
Entrée Les horloges d'entrée définissent les limites de réception d'une requête complète ; le compte à rebours débute quand une connexion à un serveur J2EE est établi. Le protocole de communication (HTTP, HTTPS) détermine l'horloge utilisé pour la requête. La session est fermée.
Session Les horloges de session définissent les délais d'utilisation des connexions de session. Elles débutent le compte à rebours dès qu'une session est en veille. La session est fermée.
Répartition WLM Les horloges de répartition contrôlent la durée d'attente d'une requête client qui doit être envoyée à une région servant en vue d'être traitée. Pour certaines horloges de répartition, vous pouvez indiquer une valeur supplémentaire désignant le pourcentage de temps de répartition comme valeur de délai d'expiration de la file d'attente WLM. Si ce délai est dépassé, le travail est retiré de la file d'attente WLM, mais aucune fin anomale n'est émise pour le servant. Le compte à rebours débute lorsque le contrôleur place la requête dans la file d'attente WLM. En fonction du minuteur spécifique, le délai peut inclure la durée d'attente dans la file d'attente WLM et la durée requise pour le traitement d'une réponse à la requête client. Message BBOO0327I pour tous les délais d'expiration.

Si le servant est arrêté, le message BBOO0232W et une fin anormale EC3 ABEND s'affichent dans le servant avec l'un des codes anomalie suivants :

  • 04130003
  • 04130004
  • 04130006
Transaction Les horloges de transaction définissent la durée
  • pendant laquelle une application ou un contrôleur attend l'exécution d'une transaction. Le compte à rebours débute lorsque le conteneur lance une transaction pour le composant d'application.
  • Un contrôleur tente de récupérer des transactions en attente de validation pendant le mode de redémarrage et de reprise homologue.
Le message BBOT0003W ou BBOO0232W et une fin anormale EC3 ABEND s'affichent dans le servant avec l'un des codes anomalie suivants :
  • 04130002
  • 04130005
Sortie Les horloges de sortie définissent la durée pendant laquelle un contrôleur attend pour recevoir la sortie d'une requête client. Le compte à rebours débute lorsque la requête client est envoyée au servant pour traitement. Le protocole de communication (HTTP ou HTTPS) détermine le minuteur employé pour la requête. Le message BBOO0232W et une fin anormale EC3 ABEND s'affichent dans le servant avec le code anomalie 04130007.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_understandingtimers
Nom du fichier : rtrb_understandingtimers.html