[z/OS]

Configurando um limite de tempo para a conclusão dos pedidos de enterprise bean RMI/IIOP

A configuração de Serviço ORB de tempo limite do Pedido determina o período no qual um cliente aguarda por uma resposta a partir de uma chamada de enterprise bean RMI/IIOP de saída. Essa configuração é uma configuração ampla do servidor que se aplica a cada código de idioma IIOP e mensagem de pedido que é enviada como um resultado de uma chamada de enterprise bean. Quando o limite de tempo especificado se expirar, o aplicativo que chamou o enterprise bean RMI/IIOP de saída receberá uma exceção do sistema org.omg.CORBA.COMM_FAILURE.

Antes de Iniciar

Para o WebSphere Application Server Versão 7 e posterior, as portas listener são descontinuadas. Portanto, você deve planejar a migração de suas configurações de implementação de bean acionado por mensagens do WebSphere MQ através do uso de portas listener para utilizar especificações de ativação. Porém, você não deve iniciar esta migração até ter certeza de que o aplicativo não precisa funcionar em servidores de aplicativos anteriores aoWebSphere Application Server Versão 7. Em alguns casos, você continuará a usar a implementação do bean acionado por mensagens e as portas listener do WebSphere MQ e, em outro caso, você usará as especificações de ativação e implementação do bean acionado por mensagens do WebSphere MQ.

As seguintes propriedades NÃO SE APLICAM à implementação de bean acionado por mensagens orientado por especificação de ativação. Isso é, as propriedades requerem que você as configure para usar a implementação de bean acionado por mensagens e portas listener do WebSphere MQ:
  • control_region_mdb_request_timeout
  • control_region_mdb_queue_timeout_percent
  • server_region_mdb_stalled_thread_dump_action
As seguintes propriedades SE APLICAM à implementação de bean acionado por mensagens orientado pela especificação de ativação. Isso é, essas propriedades requerem que você as configure para usar a implementação de bean acionado por mensagens e especificações de ativação do WebSphere MQ.
  • control_region_wlm_dispatch_timeout
  • control_region_iiop_queue_timeout_percent
  • server_region_iiop_stalled_thread_dump_action

Conforme você segue as instruções para configurar essas propriedades, lembre-se de quais propriedades aplicar a portas listener versus especificações de ativação.

Antes de começar, você deve:
  • Determinar suas configurações para todos os cronômetros de dispatch. Existem cronômetros de dispatch separados para beans acionados por mensagens (MDBs), (control_region_mdb_request_timeout), pedidos HTTP (protocol_http_timeout_output), pedidos HTTPS (protocol_https_timeout_output) pedidos SIP (protocol_sip_timeout_output), pedidos SIPS (protocol_sips_timeout_output) e pedidos IIOP (control_region_wlm_dispatch_timeout). Como as chamadas do enterprise bean podem ocorrer enquanto um aplicativo estiver em execução em um MDB, um servlet ou outro enterprise bean, você deve certificar-se de que a configuração do intervalo para o cronômetro de saída RMI/IIOP é menor do que a configuração de intervalo para qualquer um desses cronômetros de dispatch.
  • Entenda que, a partir da perspectiva do solicitador, as chamadas do enterprise bean remoto são síncronas. Portanto, enquanto o solicitador aguarda por uma resposta a partir do enterprise bean, o encadeamento de chamada é bloqueado. Quando o cronômetro RMI/IIOP expirar, o encadeamento de chamada será interrompido e retornará ao solicitador com uma resposta de exceção do sistema. Se uma resposta a partir do EJB chamado chegar DEPOIS que o cronômetro RMI/IIOP expirar, ela será ignorada.
  • Entenda o relacionamento entre o cronômetro de saída RMI/IIOP e as transações. Quando o cronômetro de saída RMI/IIOP expirar e uma exceção do sistema for retornada ao solicitador, o contêiner EJB colocará imediatamente qualquer transação global existente no estado de reversão somente. No entanto, o solicitador ainda retorna qualquer resposta do enterprise bean de destino mesmo se a transação do enterprise bean de destino estiver marcada para reversão.

Sobre Esta Tarefa

Se o cronômetro expirar, será emitida uma mensagem semelhante à seguinte:
BBOO0325W Um pedido IIOP para o Nome de Classe 'com.ejb.test.hello.second.EJSRemoteStatelessSayHelloSecond_686a0ff2' 
e o Nome do Método 'sayHelloTwo', para 'jobname=BBOS002  asid=0031', chegou ao tempo limite. 
SessionHandle=0000000026D9F0480000000A008004FF, ID do Pedido=00000004

Esta mensagem indica a classe e o método do bean corporativo de destino. Se o enterprise bean de destino foi chamado por TCP/IP, a seção "para" da mensagem contém o nome do host e a porta do servidor de destino. Se o enterprise bean de destino foi chamado por comunicação local otimizada, a seção "para" da mensagem contém o nome da tarefa de destino e asid, como mostrado no exemplo anterior.

Quando esta mensagem for emitida, um rastreio de exceção correspondente será gerado incluindo uma entrada semelhante à seguinte entrada:
/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.  
O código de erro é C9C26A48  

O código secundário C9C26A48 nessa entrada de rastreio indica que o tempo de espera para o cronômetro de saída RMI/IIOP terminou.

Se uma resposta ao pedido for recebida depois que o pedido exceder o tempo limite e não estiver mais na fila, a seguinte mensagem será emitida:
BBOO0328I: Nenhum Pedido localizado para a Resposta GIOP de entrada,
           SessionHandle=<hstring>, RequestID=<hstring>.

Um pedido ou uma resposta são identificados com exclusividade pelo handle da sessão e o ID do pedido, que podem ser utilizados para determinar se uma mensagem BBOO0325W anterior foi recebida para esse pedido.

Para alterar o período de tempo em que o cliente aguarda por uma resposta a partir de um enterprise bean chamado:

Procedimento

  1. No console administrativo, clique em Servidores > Tipos de servidores > WebSphere Application Servers > server_name > Serviço de contêiner > Serviço ORB.
  2. Especifique, em segundos, uma configuração de cronômetro apropriado no campo Tempo Limite do Pedido. O valor padrão é 180 segundos. Exemplo: Especificar um valor 2 no campo Tempo Limite de Pedido configura o tempo de espera para o cronômetro para 2 segundos.

    Recomenda-se de que você especifique um valor que seja significativamente inferior ao tempo especificado para os cronômetros de dispatch. Este tipo de configuração permite que o aplicativo de chamada seja compensado para enterprise beans não responsivos antes que o tempo de espera para o cronômetro dispatch seja encerrado. Se o tempo de espera para o cronômetro de dispatch for encerrado, pode ocorrer um EC3 ABEND.

O que Fazer Depois

Como a exceção org.omg.CORBA.COMM_FAILURE é uma exceção do sistema o aplicativo que chama o enterprise bean não é necessário para compensar ou tentar novamente uma chamada de enterprise bean expirada. No entanto, em determinadas situações, como quando as transações atômicas não estão sendo utilizadas pelo aplicativo, você talvez queira que o aplicativo compense ou tente novamente uma chamada de enterprise bean expirada.

Para que um aplicativo compense ou tente novamente uma chamada de enterprise bean expirada, o aplicativo deve:
  • Estar em execução fora da transação global atual e
  • Capture a exceção org.omg.CORBA.COMM_FAILURE.
O exemplo a seguir, que é um trecho do código que está sendo executado fora de uma transação atômica, ilustra as etapas que um aplicativo deve executar se você deseja que o aplicativo compense ou tente novamente uma chamada de enterprise bean expirada:
// Este método é executado fora de uma transação global.       
public Data callingMethod() throws … {        
     try{
            InitialContext con = new InitialContext(); 
            EJBHome home con.lookup(...);    
            CalledBean cb = home.create();   

     } catch (org.omg.CORBA.COMM_FAILURE cf1){
        // O home create poderia chegar ao tempo limite, então coloque retry ou 
        // a lógica de compensação aqui. 

     } 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){                
// O calledMethod poderia chegar ao tempo limite; portanto, então coloque retry ou 		   
// a lógica de compensação aqui. 
     } catch( … ){ 
     			… 	
     }       
}  	

// Este método pode ser executado em uma transação global.       
private void calledMethod(String strKey) throws … { 
      try{ 
             // lógica de negócio aqui 
      } 
      catch ( … ){  
                  throw new ...  
      }       
}

Os aplicativos que são executados dentro do escopo de uma transação atômica devem suspender essa transação antes de chamar um enterprise bean, se você deseja que o aplicativo consiga compensa ou tente uma chamada de enterprise bean expirado. Incorporar a chamada em um método de enterprise bean TX_NOTSUPPORTED é a melhor maneira de suspender a transação atual.


Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_svr_rmi_timer
Nome do arquivo: trun_svr_rmi_timer.html