[z/OS]

Définition d'un délai pour la réalisation des requêtes bean enterprise RMI/IIOP

Le service ORB de délai d'attente des requêtes détermine le temps pendant lequel un client attend une réponse de la part d'un appel bean enterprise RMI/IIOP sortant. Ce paramètre, qui est défini au niveau du serveur, s'applique à tous les messages de localisation et de requête IIOP qui sont envoyés suite à un appel de bean enterprise. Lorsque le délai imparti arrive à terme, l'application qui avait appelé le bean enterprise RMI/IIOP sortant reçoit une exception système org.omg.CORBA.COMM_FAILURE.

Avant de commencer

Les ports d'écoute sont obsolètes à partir de la version 7 et des versions ultérieures de WebSphere Application Server. Vous devez donc vous préparer à migrer vos configurations de déploiement de bean géré par message WebSphere MQ depuis l'utilisation des ports d'écoute vers l'utilisation des spécifications d'activation. Toutefois, vous ne devez pas commencer cette migration si vous pensez que l'application a encore besoin d'utiliser des serveurs d'applications antérieurs à WebSphere Application Server version 7. Dans certains cas, vous continuerez à utiliser les ports d'écoute et de déploiement de bean géré par message WebSphere MQ, tandis que dans d'autres, vous utiliserez les spécifications d'activation et de déploiement de bean géré par message WebSphere MQ.

Les propriétés suivantes NE s'appliquent PAS au déploiement de bean géré par message de spécification d'activation. A savoir, vous devez configurer ces propriétés pour utiliser le déploiement de beans gérés par message WebSphere MQ et les ports d'écoute :
  • 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 de spécification d'activation. A savoir, vous devez configurer ces propriétés pour utiliser le déploiement de beans gérés par message WebSphere MQ et les spécifications d'activation.
  • control_region_wlm_dispatch_timeout
  • control_region_iiop_ queue_timeout_percent
  • server_region_iiop_stalled_thread_dump_action

Lorsque vous appliquez les instructions pour configurer ces propriétés, souvenez-vous des propriétés qui s'appliquent aux ports d'écoute et celles qui s'appliquent aux spécifications d'activation.

Avant de commencer, vous devriez :
  • Déterminer vos réglages pour tous les temporisateurs d'expédition. Des temporisations distinctes et réglables individuellement sont prévues pour les beans gérés par messages (MDB) (control_region_mdb_request_timeout), les demandes HTTP (protocol_http_timeout_output), les demandes HTTPS (protocol_https_timeout_output), les demandes SIP (protocol_sip_timeout_output), les demandes SIPS (protocol_sips_timeout_output) et les demandes IIOP (control_region_wlm_dispatch_timeout). Du fait que les appels à un bean enterprise peuvent se produire quand une application est exécutée sous le contrôle d'un bean géré par messages, d'un servlet ou d'un autre bean enterprise, vous devez vous assurer que l'intervalle réglé pour le temporisateur des appels RMI/IIOP sortants est plus court que celui de ces autres temporisateurs.
  • Il est à noter que, du point de vue de l'appelant, les appels de bean enterprise distants sont synchrones. Par conséquent, alors que l'appelant attend une réponse du bean enterprise, l'unité d'exécution appelante est bloquée. Lorsque le temporisateur RMI/IIOP arrive à expiration, l'unité d'exécution appelante est interrompue et renvoie une réponse d'exception système à l'appelant. Lorsqu'une réponse de l'EJB appelé parvient APRES expiration du temporisateur RMI/IIOP, celle-ci est ignorée.
  • Comprenez la relation entre le temporisateur sortant RMI/IIOP et les transactions. Lorsque le temporisateur sortant RMI/IIOP expire et qu'une exception système est renvoyée à l'appelant, le conteneur EJB met immédiatement toute transaction globale existante en état d'annulation seulement. Néanmoins, l'appelant renvoie toujours les réponses du bean enterprise cible, même si la transaction de ce dernier est marquée pour annulation.

Pourquoi et quand exécuter cette tâche

En cas d'expiration du délai du temporisateur, un message similaire à ce qui suit est affiché :
BBOO0325W An IIOP request for Class Name 'com.ejb.test.hello.second.EJSRemoteStatelessSayHelloSecond_686a0ff2' 
and Method Name 'sayHelloTwo', to 'jobname=BBOS002  asid=0031', has timed out. 
SessionHandle=0000000026D9F0480000000A008004FF, Request ID=00000004

Ce message indique la classe et la méthode du bean enterprise cible. Si le bean enterprise cible a été appelé par le biais de TCP/IP, la section "to" du message contient le nom de l'hôte et le port du serveur cible. Si le bean enterprise est appelé par le biais d'une communication locale optimisée, la section "to" du message contient le nom de tâche cible et l'identificateur d'espace adresse, comme le montre l'exemple précédent.

Lorsque ce message est émis, une trace d'exception correspondante est générée, présentant une entrée similaire à la suivante :
/bbooejsb.cpp+3395 ... BBOO0011W The function ORBEJSBridge::invoke_request(JNIEnv *, bboojorb *, 
char *, CORBA::Boolean, CORBA::Request *&, void *)+3395 received CORBA system exception CORBA::COMM_FAILURE.  
Error code is C9C26A48  

Le code mineur C9C26A48 de cette entrée de trace indique que le temps d'attente du temporisateur sortant RMI/IIOP s'est écoulé.

Si une réponse est reçue après l'expiration de la demande et que celle-ci n'est donc plus dans la file d'attente, le message suivant est émis :
BBOO0328I: No Request found for inbound GIOP Response,
           SessionHandle=<hstring>, RequestID=<hstring>.

Une demande ou une réponse est identifiée de manière unique par le descripteur de session (SessionHandle) et l'ID de la demande (RequestID). Ces données peuvent servir à déterminer si un message BBOO0325W a été reçu plus tôt pour la demande concernée.

Pour modifier la durée pendant laquelle le client peut attendre une réponse d'un bean enterprise qu'il a invoqué :

Procédure

  1. In the administrative console, click Servers > Server Types > WebSphere application servers > server_name > Container service > ORB Service.
  2. Indiquez, en secondes, un réglage de temporisateur adéquat dans la zone Délai d'expiration de la requête. La valeur par défaut correspond à 180 secondes. Exemple : Indiquer une valeur de 2 dans la zone Délai d'expiration de la requête fixe le temps d'attente du temporisateur à 2 secondes.

    Il est recommandé d'indiquer une valeur largement inférieure à celle des temporisateurs d'expédition. Cela laisse le temps à l'application appelante de faire face à l'éventuelle absence de réponse de certains beans avant que le délai des temporisateurs d'expédition ne soit écoulé. En cas d'expiration du délai des temporisateurs d'expédition, une erreur EC3 ABEND peut se produire.

Que faire ensuite

Du fait que l'exception org.omg.CORBA.COMM_FAILURE est une exception système, il n'est pas nécessaire pour l'application appelant un bean enterprise de compenser ou de réessayer un appel ayant expiré. Cependant, dans certaines situations, par exemple, quand des transactions atomiques ne sont pas utilisées par l'application, vous pouvez exiger de l'application qu'elle compense ou qu'elle essaie à nouveau d'appeler le bean enterprise au-delà du délai.

Pour qu'une application compense ou essaie à nouveau d'appeler un bean enterprise au-delà du délai imparti, elle doit :
  • Fonctionner en dehors de la transaction globale en cours, et
  • Intercepter l'exception org.omg.CORBA.COMM_FAILURE.
L'exemple suivant, qui est un fragment de code s'exécutant en dehors d'une transaction atomique, illustre les étapes qu'une application doit respecter lorsque vous souhaitez qu'elle compense ou qu'elle essaie à nouveau d'appeler un bean enterprise au-delà du délai imparti :
// Cette méthode s'exécute en dehors d'une transaction globale.       
public Data callingMethod() throws … {        
     try{
            InitialContext con = new InitialContext(); 
            EJBHome home con.lookup(...);    
            CalledBean cb = home.create();   

     } catch (org.omg.CORBA.COMM_FAILURE cf1){
        // L'appel home.create pourrait arriver à expiration. Indiquez la logique de nouvel essai ou 
        // de compensation ici. 

     } catch( CreateException cx){  
                 throw new ...  
     } catch( NamingException nx){
                 throw new ...  
     } catch(RemoteException ex){ 
                 throw new ... 
     }
     try{
 		     	cb.calledMethod(…);

     } catch (org.omg.CORBA.COMM_FAILURE cf2){                
// La méthode calledMethod pourrait arriver à expiration. Indiquez la logique de nouvel essai ou 		   
// de compensation ici. 
     } catch( … ){ 
     			… 	
     }       
}  	

// Cette méthode peut être exécutée dans une transaction globale.       
private void calledMethod(String strKey) throws … { 
      try{ 
             // logique applicative ici 
      } 
      catch ( … ){  
                  throw new ...  
      }       
}

Les applications qui sont exécutées dans le cadre d'une transaction atomique doivent suspendre cette transaction avant d'appeler un bean enterprise si vous souhaitez que l'application puisse compenser ou essayer d'appeler un bean enterprise après expiration du délai. L'intégration de l'appel dans une méthode bean enterprise TX_NOTSUPPORTED est la meilleure façon de suspendre la transaction en cours.


Icône indiquant le type de rubrique Rubrique de tâche



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=trun_svr_rmi_timer
Nom du fichier : trun_svr_rmi_timer.html