![[z/OS]](../images/ngzos.gif)
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.
- control_region_mdb_request_timeout
- control_region_mdb_queue_timeout_percent
- server_region_mdb_stalled_thread_dump_action
- 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.
- 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
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.
/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.
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
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.
- Sie muss außerhalb der aktuellen globalen Konfiguration ausgeführt werden.
- Sie muss die Ausnahme org.omg.CORBA.COMM_FAILURE abfangen.
// 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.