Setting a time limit for the completion of RMI/IIOP enterprise bean requests
The Request timeout ORB Service setting determines how long a client waits for a response from an outbound RMI/IIOP enterprise bean invocation. This setting is a server-wide setting that applies to each IIOP locate and request message that is sent as a result of an enterprise bean invocation. When the specified time limit expires, the application that invoked the outbound RMI/IIOP enterprise bean receives an org.omg.CORBA.COMM_FAILURE system exception.
Before you begin
For WebSphere® Application Server Version 7 and later, listener ports are deprecated. Therefore you should plan to migrate your WebSphere 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 WebSphere MQ message-driven bean deployment and listener ports and in other case you will use the WebSphere MQ message-driven bean deployment and activation specifications.
- 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
As you follow the instructions to configure these properties, remember what properties apply to listener ports versus activation specifications.
- Determine your settings for all of the dispatch timers. There are separate dispatch timers for message-driven beans (MDBs), (control_region_mdb_request_timeout), HTTP requests (protocol_http_timeout_output), HTTPS requests (protocol_https_timeout_output), SIP requests (protocol_sip_timeout_output), SIPS requests (protocol_sips_timeout_output), and IIOP requests (control_region_wlm_dispatch_timeout). Because enterprise bean invocations can occur while an application is running under an MDB, a servlet or another enterprise bean, you must make sure that the interval setting for the RMI/IIOP outbound timer is shorter than the interval setting for any of these dispatch timers.
- Understand that, from the perspective of the invoker, remote enterprise bean invocations are synchronous. Therefore, while the invoker waits for a response from the enterprise bean, the invoking thread is blocked. When the RMI/IIOP timer expires, the invoking thread is interrupted and returns to the invoker with a system exception response. If a response from the invoked EJB arrives AFTER the RMI/IIOP timer expires, it is ignored.
- Understand the relationship between the RMI/IIOP outbound timer and transactions. When the RMI/IIOP outbound timer expires and a system exception is returned to the invoker, the EJB container immediately puts any existing global transaction into rollback-only state. However, the invoker still returns any response from the target enterprise bean even though the target enterprise bean's transaction is marked for rollback.
About this task
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
This
message indicates the class and method of the target enterprise bean.
If the target enterprise bean was invoked over TCP/IP, the to
section
of the message contains the hostname and the port of the target server.
If the target enterprise bean is invoked through optimized local
communication, the to
section of the message contains the target
jobname and asid, as shown in the preceding example.
/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
The minor code C9C26A48 in this trace entry indicates that the wait time for the RMI/IIOP outbound timer has ended.
BBOO0328I: No Request found for inbound GIOP Response,
SessionHandle=<hstring>, RequestID=<hstring>.
A request or reply is uniquely identified by the session handle and the request ID, and can be used to determine if an earlier BBOO0325W message was received for this request.
To change the length of time that the client waits for a response from an invoked enterprise bean:
Procedure
What to do next
Because the org.omg.CORBA.COMM_FAILURE exception is a system exception, the application invoking the enterprise bean is not required to compensate for or retry an expired enterprise bean invocation. However, in certain situations, such as when atomic transactions are not in use by the application, you might want the application to compensate for or retry an expired enterprise bean invocation.
- Be running outside of the current global transaction, and
- Catch the org.omg.CORBA.COMM_FAILURE exception.
// This method runs outside a global transaction.
public Data callingMethod() throws … {
try{
InitialContext con = new InitialContext();
EJBHome home con.lookup(...);
CalledBean cb = home.create();
} catch (org.omg.CORBA.COMM_FAILURE cf1){
// The home create could timeout, so put retry or
// compensation logic here.
} 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){
// The calledMethod could timeout, so put retry or
// compensation logic here.
} catch( … ){
…
}
}
// This method can run in a global transaction.
private void calledMethod(String strKey) throws … {
try{
// business logic here
}
catch ( … ){
throw new ...
}
}
Applications that run within the scope of an atomic transaction must suspend that transaction before invoking an enterprise bean if you want that application to be able to compensate, for or retry an expired enterprise bean invocation. Embedding the invocation in a TX_NOTSUPPORTED enterprise bean method is the best way of suspending the current transaction.