![[z/OS]](../images/ngzos.gif)
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.
- 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
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.
- 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
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.
/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.
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
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.
- Estar em execução fora da transação global atual e
- Capture a exceção org.omg.CORBA.COMM_FAILURE.
// 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.