Set a time limit for the completion of RMI/IIOP enterprise bean requests

(ZOS) 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 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.

For WebSphere Application Server Version 7 and later, listener ports are deprecated. Therefore we should plan to migrate the IBM MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, we should not begin this migration until we are sure the application does not have to work on application servers earlier than WAS v7. In some cases we will continue to use the IBM MQ message-driven bean deployment and listener ports and in other case we will use the IBM MQ message-driven bean deployment and activation specifications.

The following properties DO NOT apply to activation specification driven message-driven bean deployment. 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

The follow properties DO apply to activation specification driven message-bean deployment. 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

As you follow the instructions to configure these properties, remember what properties apply to listener ports versus activation specifications.

Before beginning, we should:

Determine our 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 DB, a servlet or another enterprise bean, 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.

If the timer expires, a message similar to the following message is issued:
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.

When this message is issued, a corresponding exception trace is generated that includes an entry similar to the following entry:
/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.

If a response to the request is received after the request times out and is no longer on the queue, the following message is issued:
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:

Tasks

In the administrative console, click...
Servers > Server Types > WebSphere application servers > server > Container service > ORB Service.
Specify, in seconds, an appropriate timer setting in the Request timeout field. The default is 180 seconds. Example: Specifying a value of 2 in the Request timeout field sets the wait time for the timer to 2 seconds.
IBM recommends that we specify a value that is significantly shorter than the time specified for the dispatch timers. This type of setting enables the invoking application to compensate for nonresponsive enterprise beans before the wait time for the dispatch timers ends. If the wait time for the dispatch timers ends, an EC3 ABEND might occur.

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, we might want the application to compensate for or retry an expired enterprise bean invocation.

For an application to compensate for or retry an expired enterprise bean invocation, the application must:

Be running outside of the current global transaction, and
Catch the org.omg.CORBA.COMM_FAILURE exception.

The following example, which is a snippet of code that is running outside an atomic transaction, illustrates the steps an application must perform if we want that application to compensate for or retry an expired enterprise bean invocation:
// 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 we 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.