Laboratório 2.4. Monitoração via Zabbix
3. Administração de EJB
3.3. Configurações de Rede para Acesso a um EJB
Este tópico foi apresentado no curso básico, então aqui faremos apenas uma revisão rápida.
Todos os serviços Java do JBoss AS 4.x, exceto o JBoss MQ (JMS), recebem re- quisições remotas à partir do mesmo conjunto de MBeans chamados de “invo- cadores”. São fornecidos vários invocadores diferentes com o JBoss, sendo dois deles mandatórios pelo padrão Java EE, e outros dois proprietários do JBoss AS. Estes invocadores são:
Tabela 3. 1 – Invocadores do JBoss AS 4
Invocador Configuração do MBean Obs
LocalInvoker conf/jboss-service.xml Invocador “fake” para chamadas dentro da mesma JVM, evitando o overhead de seri- alização e possibilitando chamadas por referência.
JRMPInvoker conf/jboss-service.xml Protocolo RMI padrão do Java SE, obri- gatório pelo padrão Java EE.
IIOPInvoker deploy/iiop-service.xml
(apenas na configuração “all”)
Protocolo IIOP padrão do CORBA, obri- gatório pelo padrão Java EE.
UnifiedInvoker conf/jboss-service.xml Baseado no JBoss Remoting, desenvolvido originalmente para o JBoss AS 5. Suas con- figurações de rede estão no MBean
jboss.remoting:service=Connector,tra nsport=socket.
PooledInvoker conf/jboss-service.xml Percursor do UnifiedInvoker, era um invo- cador RMI modificado de forma incom- patível para maior eficiência no uso de re- cursos de rede, memória e CPU.
No JBoss 4.0, não existia o invocador unificado, e todos os serviços Java usa- vam por padrão o invocador JRMP (RMI). Sugeria-se o uso do invocador poo- led caso houvesse tráfego intenso ou grande quantidade de clientes Java.
Já no JBoss AS 4.2, o invocador unificado era o padrão para todos os serviços exceto o serviço de nomes (JNDI), que permanece usando o invocador JRMP. A idéia é que o primeiro contato com o servidor de aplicações, que sempre é re-
alizado via JNDI, não necessite de muitas classes do JBoss no cliente. Depois de conectado ao JNDI, o cliente baixa do próprio servidor de aplicações as classes necessárias para falar com o serviço desejado, inclusive a implementa- ção de outros invocadores.
Então, para mudar as configurações de rede de um EJB:
• Para modificar a porta de acesso deve ser modificada a porta configura-
da no invocador correspondente, por default o unificado;
• Para habilitar acesso seguro a EJBs, é necessário habilitar o suporte a
SSL no invocador desejado, possivelmente definindo um novo MBean in- vocador, e vincular o EJB a este invocador.
• Caso se deseje configurar o acesso utilizando um protocolo alternativo,
deve ser criado uma nova configuração de invocador (<invoker-proxy- bindings>) referenciando o protocolo desejado.
A primeira situação envolve modificar a configuração do próprio MBean invo- cador. As duas situações restantes envolvem, além de possíveis modificações nas configurações de invocadores, modificar as configurações de container e/ou de invocador no standardjboss.xml ou no descritor proprietário ejb- jar.xml.
Como todas estas modificações já foram apresentadas ou no curso básico ou nas sessões anteriores deste capítulo, vamos passar para o próximo tópico.
3.3.1.
Theads para chamadas remotas
Quando ocorre uma chamada local a um EJB, isto é, o cliente é outro compo- nente dentro do mesmo servidor de aplicações12, o EJB é executado pelo mes-
mo thread que roda o componente cliente. Então não existem aqui preocupa- ções quanto à escalabilidade e consumo de recursos da rede e SO.
O cenário mais usual é o de Servlets (o que inclui JSP, Struts, JSF e outras tec- nologias web do mundo Java EE) chamando EJBs. Então basta realizar tuning dos threads dos conectores do Tomcat, pois estas mesmas threads irão execu- tar o código dos EJBs.
Entretanto, se houverem clientes remotos fazendo chamadas diretas aos EJBs (incluindo aí EJBs e Servets hospedados em servidores de aplicações diferen- tes, por exemplo outras instâncias do JBoss AS) a chamada chegará a algum invocador, que terá que aceitar a conexão e alocar um threads para processar a requisição.
No curso básico, foi apresentado o fato de que os protocolos padrão para inte- roperabilidade entre servidores de aplicação, o RMI e o IIOP, não escalam bem porque eles criam novas threads e conexões sob demanda, gerando um alto overhead de gerência de recursos de rede e SO.
É por causa disso que o JBoss AS passou a oferecer invocadores alternativos (proprietários), e que no JBoss AS 4.2 mudou-se a configuração de fábrica da
3.3. Configurações de Rede para Acesso a um EJB
maioria dos serviços para usar o invocador unificado em lugar do invocador JRMP.
O invocador pooled, que seria a outra opção com gerência de recursos em pool, permitindo tuning para performance e escalabilidade, é considerado de- preciado e é fornecido apenas para compatibilidade retroativa com aplicações escritas para versões mais anteriores do JBoss AS. Então vamos nos conentrar apenas no invocador unificado.
O invocador unificado utiliza o JBoss Remoting, um framework genérico para a construção de aplicações de rede, baseadas em objetos distribuídos. Sua configuração está no arquivo jboss-service.xml na pasta conf, apresen- tado na Listagem 3.4. Observem que o MBean UnifiedInvoker apenas faz referência ao MBean Connector do JBoss Remoting.
Listagem 3.6 – Configuração do Unified Invoker do JBoss AS (standardjboss.xml) 1 <!-- Unified invoker (based on remoting) -->
2 <mbean code="org.jboss.invocation.unified.server.UnifiedInvoker" 3 name="jboss:service=invoker,type=unified">
4 <!-- To turn on strict RMI exception propagation uncomment block
below -->
5 <!-- This will cause the UnifiedInvokerProxy to wrap RemoteExceptions
-->
6 <!-- within a ServerException, otherwise will throw root exception
--> 7 <!-- (not RemoteException) --> 8 <!-- <attribute name="StrictRMIException">true</attribute> --> 9 <depends>jboss:service=TransactionManager</depends> 10 <depends>jboss.remoting:service=Connector,transport=socket</depends> 11 </mbean>
O conector do JBoss Remoting está definido no mesmo arquivo, e com os atri- butos para o tamanho do pool de threads comentado, portanto com valores de- faults. A Listagem 3.7 mostra os trechos relevantes do arquivo.
Listagem 3.7 – Configuração do Conector do JBoss Remoting no JBoss AS (standardj- boss.xml)
1 <!-- The Connector is the core component of the remoting server service.
-->
2 <!-- It binds the remoting invoker (transport protocol, callback
configuration, -->
3 <!-- data marshalling, etc.) with the invocation handlers. --> 4 <mbean code="org.jboss.remoting.transport.Connector"
5 name="jboss.remoting:service=Connector,transport=socket"
6 display-name="Socket transport Connector"> 7 ... 8 <!-- <attribute name="numAcceptThreads">1</attribute>--> 9 <attribute name="maxPoolSize">303</attribute> 10 <attribute name="clientMaxPoolSize" isParam="true">3</attribute> ... 11 <!-- <attribute name="backlog">200</attribute>--> 12 ...
Observe que existem dois “MaxPoolSize”s na listagem. Isto ocorre porque o JBoss Remoting multiplexa uma única conexão TCP, que pode ser compartilha- da por vários threads na mesma JVM de cliente. Isto evita uma explosão na quantidade conexões TCP, que poderia superar o limite do SO subjacente. A multiplexação de conexões no cliente ocorre em adição ao compartilhamento em pool das conexões no servidor:
• O limite do cliente (clientMaxPoolSize) limita a quantidade de threads
que serão alocadas no cliente para enviar requisições pela conexão com- partilhada, ou seja, limitam a quantidade de chamadas em paralelo que um cliente poderá realizar.
• Já o limite do servidor (MaxPoolSize) limita a quantidade de threads do
servidor que irão receber e processar as requisições. Em um ambiente que faça bastante uso de chamadas remotas a EJBs, este pode ser um forte fator limitante para performance, ou pode ser uma boa forma de li- mitar a carga de trabalho no ambiente.
3.3.2.
Monitoração do Invocador Unificado
Para monitorar a utilização do pool de threads do invocador unificado, deve ser utilizado um MBean de nome gigante, gerado pela concatenação de quase todos os atributos do conector. Felizmente ele pode ser localizado por uma busca JMX simples:
jboss.remoting:port=4446,*
Onde o número 4446 deve ser substituído pela porta TCP configurada para o JBoss Remoting.
O nome do EJB é gigante, o que pode ser um problema para algumas ferra- mentas de monitoração. Mas o twiddle pode ser utilizado para copiar e colar o nome completo do MBean.
Os atributos relevantes para a monitoração são
• CurrentClientPoolSize é o total de threads ocupadas atendendo requi-
sições dos clientes. Este nome engana, pois sugere que seria a quantida- de de threads ocupadas no lado cliente, mas na verdade refere-se aos th- reads no lado servidor;
3.3. Configurações de Rede para Acesso a um EJB
• CurrentThreadPoolSize é o total de threads disponíveis para atender a
novas requisições, ou seja, que estão ociosas no momento.
tuning e monitoração do invocador unificado afeta TODOS os EJBs de- ployados no servidor de aplicações, ou melhor, todos os que aceitam cha- madas remotas. Gargalos causados por uma aplicação, que tenha ua quan- tidade elevada de clientes ou requisições; ou falhas de programação em um único EJB, que fique “em loop” nas suas chamadas, segurando threads e conexões do JBoss Remoting, irão afetar TODOS os EJBs, mesmo aqueles em pacotes separa- dos.