[z/OS]

Zeitlimit für die Ausführung von RMI/IIOP-Enterprise-Bean-Anforderungen festlegen

Die Einstellung für das Anforderungszeitlimit des ORB-Service bestimmt, wie lange ein Client auf eine Antwort auf einen abgehenden RMI/IIOP-Enterprise-Bean-Aufruf wartet. Diese Einstellung ist eine serverseitige Einstellung, die für alle IIOP-Such- und -Anforderungsnachrichten gilt, die auf den Aufruf einer Enterprise-Bean hin gesendet werden. Wenn das angegebene Zeitlimit abläuft, empfängt die Anwendung, die die abgehende RMI/IIOP-Enterprise-Bean aufgerufen hat, eine Systemausnahme vom Typ org.omg.CORBA.COMM_FAILURE.

Vorbereitende Schritte

Für WebSphere Application Server Version 7 und höher sind Listener-Ports veraltet. Deshalb sollten Sie die WebSphere MQ-MDB-Implementierungskonfigurationen von Listener-Ports auf Aktivierungsspezifikationen umstellen. Sie sollten diese Migration jedoch erst dann durchführen, wenn Sie sicher sind, dass die Anwendung nicht in Anwendungsservern einer früheren Version als WebSphere Application Server Version 7 ausgeführt werden muss. In einigen Fällen werden Sie weiterhin die WebSphere MQ-MDB-Implementierung mit Listener-Ports und in anderen Fällen die WebSphere MQ-MDB-Implementierung mit Aktivierungsspezifikationen verwenden.

Die folgenden Eigenschaften gelten nicht für die MDB-Implementierung mit Aktivierungsspezifikationen. Das heißt, Sie müssen diese Eigenschaften für die WebSphere MQ-MDB-Implementierung mit Listener-Ports konfigurieren:
  • control_region_mdb_request_timeout
  • control_region_mdb_queue_timeout_percent
  • server_region_mdb_stalled_thread_dump_action
Die folgenden Eigenschaften gelten für die MDB-Implementierung mit Aktivierungsspezifikation. Das heißt, Sie müssen diese Eigenschaften für die WebSphere MQ-MDB-Implementierung mit Aktivierungsspezifikationen konfigurieren.
  • control_region_wlm_dispatch_timeout
  • control_region_iiop_queue_timeout_percent
  • server_region_iiop_stalled_thread_dump_action

Folgen Sie den Anweisungen zur Konfiguration dieser Eigenschaften, und beachten Sie, welche Eigenschaften für Listener-Ports bzw. Aktivierungsspezifikationen gelten.

Bevor Sie beginnen, sollten Sie Folgendes beachten:
  • Bestimmen Sie die Einstellungen für alle Zuteilungszeitgeber. Es gibt gesonderte Zuteilungszeitgeber für nachrichtengesteuerte Beans (control_region_mdb_request_timeout), HTTP-Anforderungen (protocol_http_timeout_output), HTTPS-Anforderungen (protocol_https_timeout_output), SIP-Anforderungen (protocol_sip_timeout_output), SIPS-Anforderungen (protocol_sips_timeout_output) und IIOP-Anforderungen (control_region_wlm_dispatch_timeout). Da der Aufruf einer Enterprise-Bean erfolgen kann, während eine Anwendung unter einer nachrichtengesteuerten Bean (MDB, Message-Driven Bean), einem Servlet oder einer anderen Enterprise-Bean ausgeführt wird, müssen Sie sicherstellen, dass die Intervalleinstellung für den Zeitgeber für abgehende RMI/IIOP-Anforderungen kürzer ist als die Intervalleinstellung für jeden dieser Zuteilungszeitgeber.
  • Aus der Perspektive des Aufrufenden sind Aufrufe ferner Enterprise-Beans synchron. Während der Aufrufende auf eine Antwort der Enterprise-Bean wartet, ist der aufrufende Thread blockiert. Wenn der RMI/IIOP-Zeitgeber abläuft, wird der aufrufende Thread unterbrochen mit einer Systemausnahme wieder an den Aufrufenden übergeben. Sollte nach Ablauf des RMI/IIOP-Zeitgebers eine Antwort von der aufgerufenen EJB eingehen, wird diese ignoriert.
  • Machen Sie sich mit der Beziehung zwischen dem Zeitgeber für abgehende RMI/IIOP-Anforderungen und Transaktionen vertraut. Wenn der Zeitgeber für abgehende RMI/IIOP-Anforderungen abläuft und eine Systemausnahme an den Aufrufenden zurückgegeben wird, versetzt der EJB-Container alle vorhandenen globalen Transaktionen unverzüglich in den Status "rollback-only". Der Aufrufende gibt jedoch weiterhin alle Antworten der Ziel-Enterprise-Bean zurück, selbst wenn die Transaktion der Ziel-Enterprise-Bean für Rollback gekennzeichnet ist.

Informationen zu diesem Vorgang

Wenn der Zeitgeber abläuft, wird eine Nachricht wie folgende ausgegeben:
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

Diese Nachricht enthält die Klasse und die Methode der Ziel-Enterprise-Bean. Wenn die Ziel-Enterprise-Bean über TCP/IP aufgerufen wurde, enthält der Abschnitt "to" der Nachricht den Hostnamen und den Port des Zielservers. Wenn die Ziel-Enterprise-Bean über eine optimierte lokale Kommunikation aufgerufen wurde, enthält der Abschnitt "to" der Nachricht, wie im vorherigen Beispiel gezeigt, den Namen des Zieljobs und die asid-Angabe.

Wenn diese Nachricht ausgegeben wird, wird ein entsprechender Ausnahmetrace generiert, der einen Eintrag ähnlich dem folgenden enthält:
/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  

Der Nebencode C9C26A48 in diesem Traceeintrag gibt an, dass die Wartezeit für den Zeitgeber für abgehende RMI/IIOP-Anforderungen abgelaufen ist.

Wenn eine Antwort auf die Anforderung nach Ablauf des Anforderungszeitlimits empfangen wird und sich die Anforderung nicht mehr in der Warteschlange befindet, wird die folgende Nachricht ausgegeben:
BBOO0328I: No Request found for inbound GIOP Response,
           SessionHandle=<hstring>, RequestID=<hstring>.

Eine Anforderung oder Antwort wird eindeutig über das Sitzungshandle und die Anforderungs-ID identifiziert und kann verwendet werden, um festzustellen, ob eine frühere BBOO0325W-Nachricht für diese Anforderung empfangen wurde.

Wenn Sie die Wartezeit des Clients auf eine Antwort einer aufgerufenen Enterprise-Bean ändern möchten, gehen Sie wie folgt vor:

Vorgehensweise

  1. Klicken Sie in der Administrationskonsole auf Server > Servertypen > WebSphere-Anwendungsserver > Servername > Container-Service > ORB-Service.
  2. Geben Sie im Feld "Anforderungszeitlimit" eine entsprechende Zeitgebereinstellung ein. Der Standardwert ist 180 Sekunden. Wenn Sie im Feld "Anforderungszeitlimit" beispielsweise den Wert 2 eingeben, wird die Wartezeit für den Zeitgeber auf 2 Sekunden gesetzt.

    Es wird empfohlen, einen Wert anzugeben, der erheblich kleiner ist als der Wert, den Sie für die Zuteilungszeitgeber angegeben haben. Diese Art von Einstellung ermöglicht der aufrufenden Anwendung, nicht reagierende Enterprise-Beans zu kompensieren, bevor die Wartezeit für die Zuteilungszeitgeber abläuft. Wenn die Wartezeit für die Zuteilungszeitgeber abläuft, kann ein EC3 ABEND auftreten.

Nächste Schritte

Da die Ausnahme org.omg.CORBA.COMM_FAILURE eine Systemausnahme ist, muss die Anwendung, die die Enterprise-Bean aufruft, einen Enterprise-Bean-Aufruf, der das zulässige Zeitlimit überschreitet, weder kompensieren noch wiederholen. In bestimmten Situationen, z. B., wenn keine atomaren Transaktionen von der Anwendung verwendet werden, kann es jedoch wünschenswert sein, dass die Anwendung einen Enterprise-Bean-Aufruf, der das zulässige Zeitlimit überschreitet, kompensiert oder wiederholt.

Eine Anwendung, die einen Enterprise-Bean-Aufruf, der das zulässige Zeitlimit überschreitet, kompensieren oder wiederholen soll, muss folgende Kriterien erfüllen:
  • Sie muss außerhalb der aktuellen globalen Konfiguration ausgeführt werden.
  • Sie muss die Ausnahme org.omg.CORBA.COMM_FAILURE abfangen.
Das folgende Beispiel, das ein Code-Snippet ist, das außerhalb einer atomaren Transaktion ausgeführ wird, veranschaulicht die Schritte, die eine Anwendung ausführen muss, wenn sie einen Enterprise-Bean-Aufruf, der das zulässige Zeitlimit überschreitet, kompensieren oder wiederholen soll:
// Diese Methode wird außerhalb einer globalen Transaktion ausgeführt. public Data callingMethod() throws … {        
     try{
            InitialContext con = new InitialContext(); 
            EJBHome home con.lookup(...);    
            CalledBean cb = home.create();   

     } catch (org.omg.CORBA.COMM_FAILURE cf1){
        // home.create könnte das zulässige Zeitlimit überschreiten,
        // deshalb muss die Logik für die Wiederholung bzw.
        // Kompensation hier eingefügt werden. 

     } 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){                
// calledMethod könnte das zulässige Zeitlimit überschreiten,
// deshalb muss die Logik für die Wiederholung bzw.
// Kompensation hier eingefügt werden. 
     } catch( … ){ 
     			… 	
     }       
}  	

// Diese Methode kann in einer globalen Transaktion ausgeführt werden. private void calledMethod(String strKey) throws … { 
      try{ 
             // Geschäftslogik hier einfügen 
      } 
      catch ( … ){  
                  throw new ...  
      }       
}

Anwendungen, die im Geltungsbereich einer atomaren Transaktion ausgeführt werden, müssen diese Transaktion aussetzen, bevor sie eine Enterprise-Bean aufrufen, wenn Sie möchten, dass die Anwendung einen Enterprise-Bean-Aufruf, der das zulässige Zeitlimit überschreitet, kompensiert bzw. wiederholt. Das Einbetten des Aufrufs in die Enterprise-Bean-Methode TX_NOTSUPPORTED ist die beste Methode zum Aussetzen der aktuellen Transaktion.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_svr_rmi_timer
Dateiname:trun_svr_rmi_timer.html