(zos)

Set 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.

For WebSphere Application Server Version 7 and later, listener ports are deprecated. Therefore you should plan to migrate the 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.

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 WebSphere MQ message-driven bean deployment and listener ports:

The follow properties DO apply to activation specification driven message-bean deployment. That is, these properties require you to configure them to use the WebSphere MQ message-driven bean deployment and activation specifications.

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

Before beginning, you should:

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:

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:

  1. In the console, click Servers > Server Types > WebSphere application servers > server_name > Container service > ORB Service.

  2. Specify, in seconds, an appropriate timer setting in the Request timeout field. The default value 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 specified 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, you 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:

The following example, which is a snippet of code running outside an atomic transaction, illustrates the steps an application must perform if you 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 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.