Mostrando postagens com marcador Java. Mostrar todas as postagens
Mostrando postagens com marcador Java. Mostrar todas as postagens

quinta-feira, 11 de fevereiro de 2021

Selenium Java - Como limpar campos

 INTRODUÇÃO

Vamos mostrar nessa publicação maneiras de se limpar os campos, para que na execução funcione corretamente.


PROCEDIMENTO

// Busca elemento do driver, passando o By
WebElement elemento = driver.findElement(by);
// Seleciona texto do começo do campo até o fim, segurando SHIFT e depois, aplica o Backspace
elemento.sendKeys(Keys.HOME, Keys.chord(Keys.SHIFT, Keys.END), Keys.BACK_SPACE);

// Seleciona todo o texto dando o comando "CONTROL + A" e depois, aplica o Backspace
elemento.sendKeys(Keys.chord(Keys.CONTROL, "a"), Keys.BACK_SPACE);

// Apaga qualquer texto no componente
elemento.clear();

OBSERVAÇÕES

O motivo de estarmos usando praticamente três funções "repetidas" é porque durante a execução, a função "elemento.clear()" não funciona corretamente, ora limpa o campo, ora não limpa.
Da mesma maneira para as outras funções. Pois alguns componentes podem ter lógica JavaScript embutida sendo executada, navegadores distintos podem ter comportamentos distintos para a mesma execução do selenium para o mesmo campo e outros problemas.


REFERÊNCIAS

https://www.selenium.dev/documentation/en

terça-feira, 4 de agosto de 2020

Criando arquivo .sh para executar aplicação Java com passagem de parâmetros

Conforme mostrado no artigo http://www.josepojr.com/2020/07/criando-arquivo-bat-para-executar.html
a configuração para Windows, mas para Linux, temos pequenas mudanças conforme exemplo abaixo:


java -Dfile.encoding=UTF-8 -cp ".:libs/*" pacote.minha.classe.Main $*

Aonde "$*" permite que passamos parâmetros dentro da execução do script .sh no Linux.
Também, alteramos o símbolo separador de path do windows que é um ponto-e-vírgula ";" para dois pontos ":" e colocamos aspas no valor do parâmetro "cp".
Importante não deixa espaço em branco depois de "$*" para a aplicação Java não entender que aquele espaço em branco é um argumento passado para o programa.

Criando shell script para executar aplicações Java no Linux com dependências

INTRODUÇÃO


Nessa publicação explicaremos como criar o arquivo .sh para iniciar uma aplicação Java com as suas dependências (Pastas libs contendo Jars, por exemplo). Para isto, vamos criar uma aplicação simples chamada "ExemploJava".


CONFIGURAÇÃO


Essa aplicação terá uma pasta chamada "libs" para conter os jars de bibliotecas de terceiros que a aplicação pode usar (ou não) e será referenciada no classpath da aplicação Java.

Outra pasta chamada de "bin" conterá os pacotes e classes do projeto. Por exemplo, se tivermos uma classe fictícia chamada "A" dentro do pacote "a.b.c", portanto o nome completo da classe será "a.b.c.A". E dentro da pasta "bin", teremos a pasta "a" e dentro desta a pasta "b". E por último, dentro da pasta "b", teremos a pasta "c" que conterá o arquivo "A.java" definindo a classe pública "A".

Estas duas pastas estarão dentro da pasta "ExemploJava" e o script .sh ("exemploJava.sh" por exemplo) estará dentro desta pasta.

Para efeito prático, vamos adotar a classe "A" como a classe com o método main (inicializadora da aplicação Java).

Portanto, o conteúdo do arquivo .sh será:

java -Dfile.encoding=UTF-8 -cp ".:bin/:libs/*:" a.b.c.A 


Aonde temos:

-Dfile.encoding=UTF-8
aonde informa a codificação usada, muito recomendável usar unicode no UTF-8 pois é uma codificação internacional e preparada para lidar com diversos alfabetos e idiomas.


-cp ".:bin/:libs/*:"
aonde informamos as pastas, jars e arquivos .class que estarão no classpath. Estando no classpath, nossa aplicação pode carregar e usar as classes. Se não estiver no classpath, pode dar erros em tempo de execução, lançado exceções dos tipos "java.lang.ClassNotFoundException" ou "java.lang.NoClassDefFoundError" por exemplo. Além disso, se forem colocados paths (caminhos) errados, ao rodar a aplicação não dará erro a priori (por causa desses paths sem jars ou arquivos .class), mas quando a classe Main for executada e for carregando as dependências, pode chegar numa classe que não estará no classpath. Portanto, muito cuidado para colocar o caminho correto para que as dependências dentro desses caminhos sejam carregadas corretamente para dentro da JVM.

Nesse exemplo, usamos a pasta bin para conter os arquivos .class ou recursos. Mas também é possível empacotar tudo num jar e colocar nesse argumento diretamente (":meuarquivo.jar") ou colocar esse jar na pasta "bin" ou "libs".
Lembrando também que os dois-pontos ":" é o separador de paths (caminhos) entre um jar ou diretório do outro. O sinal ponto "." representa o diretório atual que o script está sendo rodado.


a.b.c.A
É o nome completo para a classe Main que será iniciada pela JVM no comando "java".
Sem essa classe Main, o comando "java" abortará, mostrando uma mensagem de erro dizendo que não foi informado uma classe com o método estático "void main(String args[])".


OBSERVAÇÃO


Muito importante, depois da classe main "A", deverá ter um espaço em branco!
Caso contrário, ao executar o script sh, dará erros dizendo que a classe "a.b.c.A" não foi localizada e nem carregada! Pois, o shell script fornecerá como parâmetro a classe de nome completo "a.b.c.A\n" com a QUEBRA DE LINHA inclusa! E logicamente, no nosso classpath (formado pelo núcleo do Java e mais as pastas informadas no parâmetro "cp") essa classe de nome completo "a.b.c.A\n" não existirá! E pior, difícil de localizar esse tipo de erro, pois a quebra de linha "\n" fica invisível no terminal!

segunda-feira, 6 de julho de 2020

Criando arquivo .bat para executar aplicação Java com passagem de parâmetros

Nesse artigo, vamos mostrar como fazer a criação do arquivo .bat para ser executado no sistema operacional Windows, chamando uma aplicação Java e podendo passar parâmetros.

Para isso, vejam esse exemplo:


set PARAMETROS=%*
java -Dfile.encoding=UTF-8 -cp .;libs/* pacote.minha.classe.Main %PARAMETROS%



Aonde a variável "PARAMETROS" define a maneira de passar o parâmetro na execução do arquivo.bat.

Para executar esse bat, salve como "arquivo.bat" e depois execute em linha de comando digitando da seguinte maneira:

arquivo.bat a b c

Aonde os parâmetros "a", "b" e "c" serão passados para a classe Main declarada em "pacote.minha.classe.Main" aonde informa a classe com o método estático "void main(String args[])" aonde que em Java é o método que é chamado na execução de um programa.

Portanto, esses parâmetros passados estarão contidos na variável "args"do programa Java. Logicamente, nesse exemplo, estou usando o parâmetro com o nome "args", mas se o nome for diferente, a passagem dos parâmetros ocorrerá normalmente e sua aplicação poderá passar!

Para o parâmetro ".;libs/*" indica uma pasta chamada "libs" e todos os jars que estiverem contidas dentro dessa pasta serão carregados no classpath da aplicação, se caso for necessário. E o "." indica o diretório atual, para procurar jars no mesmo diretório do arquivo.bat. E por último, o ";" apenas separa os diretórios listados, podendo carregar vários diretórios de jars para a aplicação rodar.

Temos abaixo um exemplo de classe Main:

public class Main {

    public static void main(String args[]) {
        for(int i=0; i < args.length; i++) {
             System.out.println("Parametro passado: " + args[i]);
        }
   }
}

Também é possível chamar diretamente o jar no arquivo.bat:

set PARAMETROS=%*
java -jar A.jar %PARAMETROS%

Aonde temos todas as dependências do jar embutidas num único jar.

segunda-feira, 13 de novembro de 2017

Problemas no uso do método System.currentTimeMillis() e uso do método System.nanoTime() na linguagem Java



INTRODUÇÃO

No desenvolvimento de sistemas usando a linguagem Java, é corriqueiro o uso do método de obter a quantidade de milissegundos do tempo atual (contando desde 1970).
Mas nesse artigo mostraremos problemas na chamada sucessiva desse método (que retorna o mesmo valor, como o tempo não "andasse") e possível solução para contornar os problemas.


PROBLEMA

Ao executarmos o seguinte código Java:



import java.text.SimpleDateFormat;
import java.util.Calendar;

public class TesteTempos {

    public static void main(String[] args) {
       
         final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd_HHmmssS");

         final long time1 = System.currentTimeMillis();
         final long time2 = System.currentTimeMillis();
       
         final long nano1 = System.nanoTime();
         final long nano2 = System.nanoTime();
       
         final String txt1 = sdf.format(Calendar.getInstance().getTime());
         final String txt2 = sdf.format(Calendar.getInstance().getTime());
       
         System.out.println(time1);
         System.out.println(time2);
         System.out.println();
         System.out.println(nano1);
         System.out.println(nano2);
         System.out.println();
         System.out.println(txt1);
         System.out.println(txt2);
    }
}



Resultado (no console):

1510339299662
1510339299662

2068554850479041
2068554850479809

20171110_164139662
20171110_164139663


Note que as duas chamadas de System.currentTimeMillis() geram o mesmo valor. Isso é ruim num processamento num servidor JavaEE (por exemplo) aonde queremos tempos diferentes e não iguais! Se temos tempos iguais, nosso código pode dar erros em tempo de execução em alguma lógica que obrigue ser diferente (Exemplo: uso da data como parte da chave primária composta de um banco de dados).


SOLUÇÃO

Usar a chamada System.nanoTime() para gerar valores sempre distintos caso necessitamos (por exemplo, queremos inserir dois registros no banco de dados, sendo que esses tempos são parte de chave primária composta da tabela do banco de dados). Nesse caso, evitamos que a JVM retorne valores iguais!

Note também que a chamada a Calendar.getInstance().getTime() tem praticamente o mesmo efeito da chamada System.currentTimeMillis(), mas a diferença de 1 milissegundos está no fato no tempo de formatação da data pelo objeto da classe java.text.SimpleDateFormat.


CONCLUSÃO

Nesse artigo mostramos problemas no uso sucessivo da chamada System.currentTimeMillis() e maneiras de contorná-los! Em muitos casos envolvendo regras de negócio que necessitem chamadas sucessivas de tempos atuais, mas que retornem valores distintos, importante ter atenção e usar o método System.nanTime().


segunda-feira, 23 de junho de 2014

Apache Web Service + JBoss Mod cluster (Loadbalance) + JBoss AS 7 no CentOS 6.5 - 64 bits


INTRODUÇÃO

explicamos detalhadamente a instalação do Apache Web Service (conhecido como "httpd") com o JBoss Mod Cluster já instalado. Nesse artigo, vamos explicar a configuração para o Apache Web Service "limpo", isto é, o httpd instalado no CentOS sem nenhum módulo adicional, em outras palavras, com a configuração padrão do httpd para o CentOS.



DESENVOLVIMENTO

Instalando e configurando o Apache Web Service (httpd).

Instalar os seguintes pacotes no CentOS 6.5 64 bits.

yum install httpd httpd-devel apr-devel openssl-devel mod_ssl -y

Depois disso, iniciar serviço do httpd com o comando:

service httpd start

Ou na interface gráfica dentro do CentOS, No menu "Sistema" > "Administração" > "Serviços", conforme mostra a figura a seguir:



Depois de iniciar o servidor httpd, o resultado no endereço http://127.0.0.1 (local) ou outro endereço que está configurado na interface de rede do CentOS, deve ser a página inicial do servidor httpd, conforme mostra a figura a seguir:





Depois de testar o servidor httpd, agora baixe (desligue) o httpd que vamos inserir módulos do projeto JBoss ModCluster para poder configurar o loadbalance (Balanceador de carga, isto é, de requisições HTTP).

Para isso, entre nesse site: http://mod-cluster.jboss.org/
faça o download da versão 1.2.6.Final para o sistema operacional linux-x86_64

Observação: Não baixe as versões que venha com o httpd incluído, pois estaremos usando o httpd fornecido dentro dos repositórios de pacotes .rpm do CentOS 6.5. Dá para notar que o tamanho do arquivo com o httpd é da ordem de megabytes, enquanto o arquivo só com os módulos é da ordem de kilobytes.

Ao baixar o arquivo, descompacte o arquivo *.tar.gz com o seguinte comando:

tar xvfz mod_cluster-1.2.6.Final-linux2-x64-so.tar.gz 

Dentro do arquivo compactado, teremos 4 arquivos binários com a extensão *.so que são:

mod_advertise.so
mod_manager.so
mod_proxy_cluster.so
mod_slotmem.so

Esses são os 4 módulos que vão ser inseridos na pasta /etc/httpd/modules, então, deve-se copiar esses arquivos para esse diretório, tomando cuidado para que o dono e grupo dos arquivos sejam sempre root.
Caso contrário, ao iniciar o httpd, o mesmo reportará erros de permissão nos módulos e não conseguirá ser iniciado.

Agora vamos para o diretório  /etc/httpd/conf e edite o arquivo httpd.conf com os seguintes dados:

Comente a linha do módulo proxy_balancer_module para não entrar em conflito com o modulo de proxy do JBoss Cluster (mod_proxy_cluster) que estaremos incluindo:

#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

Insira as seguintes linhas depois das outras linhas com o nome "LoadModule":

LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so


Inserir a seguinte linha depois da linha com o comando "Include conf.d/*.conf"

MemManagerFile /var/cache/mod_cluster

Por último, inserir o comando "IfModule" para o módulo "manager_module" conforme mostra código a seguir:

<IfModule manager_module>
   Listen 0.0.0.0:6666
   ManagerBalancerName mycluster
   <VirtualHost *:6666>
       <Location />
       Order deny,allow
       Deny from all
       Allow from all
  
       KeepAliveTimeout 300
       MaxKeepAliveRequests 0
       ServerAdvertise Off
       EnableMCPMReceiver Off
  
       <Location /mod_cluster_manager>
            SetHandler mod_cluster-manager
            Order deny,allow
            Deny from all
            Allow from all
       </Location>
   </VirtualHost>
</IfModule>


Depois disso, iniciar o servidor com o comando:

service httpd start

Observação: Nesse momento, é importante iniciar o servidor dessa maneira para que o mesmo possa imprimir no console os erros que possam ocorrer. Se iniciar pela interface gráfica e se tiver erros no arquivo httpd.conf, o servidor não iniciará e ficar com um alerta dizendo que está morto, ou a interface gráfica ficará travada. Também podemos olhar os logs no diretório /etc/httpd/logs mas o trabalho para chegar até ai e usar os velhos comandos como tail -f error.log seria muito demorado. Quando ocorre erros, o erro já foi reportado no próprio console, depois de executar o comando service httpd start.


Configurando o JBoss AS 7 para funcionar com o httpd + mod_cluster

Próximo passo é configurar o JBoss AS 7 para se conectar no httpd com o mod_cluster instalado. Para isso, altere o arquivo de configuração standalone-full-ha.xml da pasta $JBOSS_HOME/standalone/configuration conforme as configurações abaixo:

<subsystem xmlns="urn:jboss:domain:modcluster:1.1">
    <mod-cluster-config advertise-socket="modcluster" proxy-list="127.0.0.1:6666" connector="ajp">
         <dynamic-load-provider history="10" decay="2">
              <load-metric type="cpu" weight="2" capacity="1" />
              <load-metric type="sessions" capacity="512" />
         </dynamic-load-provider>
    </mod-cluster-config>
</subsystem>

<subsytem xmlns="urn:jboss.domain:web:1.2" default-virtual-server="default-host" instance-id="%{jboss.node.name}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" />
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" />
    <virtual-server name="default-host" enable-welcome-root="true" >
          <alias name="localhost" />
    </virtual-server>
</subsystem>

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}" >
    <socket-binding name="ajp" port="8009" />
    <socket-binding name="http" port="8080" />

</socket-binding-group>

Depois disso, abrir navegador no endereço http://127.0.0.1, conforme mostra a figura seguir:



Note que a página inicial do httpd "sumiu", isto é, ficou no lugar da página inicial do JBoss AS 7. Isso mostra que o balanceador de carga (mod_cluster) + httpd (servidor web) estão funcionando juntos e corretamente!



CONCLUSÃO

Mostramos nesse artigo como configurar, instalar o JBoss ModCluster dentro do Apache Web Service e assim, funcionando junto com o servidor JBoss AS 7. Lembrando que podemos instanciar N servidores jboss para trabalhar com o mesmo servidor httpd, desta maneira, se um servidor jboss cair (for derrubado), o httpd com o mod_cluster instalado, detectará que uma instância do cluster de JBoss AS 7 caiu e não enviará mais requisições a essa instância.

Para realizar o acesso externo no CentOS, veja mais informações nesse link: http://tidahora.com.br/index.html/doku.php?id=instalando_o_mantis_no_centos_6. Esse artigo cita a instalação de um outro programa web como o Mantis (https://www.mantisbt.org/), mas cita a desativação do serviço SELINUX com a edição do arquivo /etc/selinux/config e pede para mudar a seguinte linha:

SELINUX = disabled

Para desabilitar o SELINUX. Depois, no menu "Sistema" > "Administração" > "Firewall" e configure o par porta/protocolo para o Firewall deixar fazer o acesso. Lembrando de clicar em "Aplicar" para as configurações possam estar valendo no sistema.
Por último, configurar o Iptables no linux para deixar realizar o acesso pelas portas necessárias. A configuração disso está fora do escopo desse artigo, podendo ser realizada pelo link http://www.guiafoca.org/cgs/guia/avancado/ch-fw-iptables.html.
Ou como solução paliativa e para fins de desenvolvimento e testes, pode se desativar o serviço de Iptables no menu "Sistema" > "Administração" > "Serviços".


REFERÊNCIAS

http://jbossdivers.wordpress.com/2014/03/23/configurando-um-ambiente-wildfly-8-profissional/






sexta-feira, 11 de outubro de 2013

Ordem de carregamento de classes / jars no JBoss AS 7


INTRODUÇÃO

Nesse blog escrevi sobre isolamentos de classloaders no JBoss AS 7.
Vejam nesse link:

http://www.josepojr.com/2013/01/isolamento-de-classloaders-no-jboss-as-7.html

Mas gostaria de complementar com mais explicações sobre a ordem usada no carregamento de classes / jars no JBoss AS 7.


CONCEITOS

1 - Só criar módulos no JBoss 7 se for alguma API que será usada em vários projetos (WAR ou EAR) que serão implantados (deploy) no JBoss 7.

2 - Dentro de um EAR, pode-se colocar os jars dentro dos seus respectivos subprojetos. Ou seja, se no seu EAR tem dois wars e um jar (Projeto EJB), um jar que será usado em somente um war, pode ser colocado dentro da pasta WEB-INF/lib desse respectivo war. Agora, se o seu jar é usado em todos os subprojetos do ear, usar dentro do diretório EAR/lib.

3 - O JBoss 7 tem uma regra de procedência para decidir qual classe de qual jar carregar primeiro. Veja em:

https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7


Resumindo a regra usada, de acordo com a prioridade:

1º Carregar classes de sistemas do JRE e JavaEE (especificação).
2º Dependências declaradas explicitamente no arquivo jboss-deployment-structure.xml
3º Classes / jars internos dos subprojetos como WEB-INF/classes ou WEB-INF/lib para um projeto WAR.
4º Jars contidos na pasta EAR/lib do seu projeto EAR.


Essas regras são muito importantes para o desenvolvimento de aplicações no JBoss AS 7. Se sua classe estiver no mesmo pacote e mesmo nome (exemplo meupacote.MinhaClasse) e estiver em dois lugares como WEB-INF/lib e EAR/lib, o JBoss AS 7 carregará a classe que achará primeiro. E pela regra da prioridade, pegará a classe MinhaClasse que está no jar do subprojeto WAR pasta WEB-INF/lib. Se a classe MinhaClasse estiver também em um outro jar da pasta EAR/lib, a classe nesse pacote não será carregada.


CONCLUSÃO

A equipe de projeto e desenvolvimento do JBoss AS 7, tiveram que elaborar algum mecanismo para definir em casos de "dúvidas" qual classe será carregada, no caso de existirem classes como mesmo nome e pacote dentro do servidor JBoss AS 7. Essas regras visam tomar decisões para em tempo de execução, o JBoss AS 7 resolver o impasse e escolher uma classe dentro de um conjunto de N classes de mesmo pacote e nome. Claro que nesse cenário estamos lidando com o pior caso, de temos a mesma classe e no mesmo pacote e M versões distintas e rodando no mesmo servidor de aplicações JBoss AS 7.



quarta-feira, 24 de abril de 2013

Criando Cluster de JBoss AS 7 com Load Balance (JBoss mod_cluster + httpd)




INTRODUÇÃO


Loadbalance é uma aplicação que recebe uma requisição HTTP, e decide qual instância (servidor) chamar de um cluster de servidores. Nesse caso, estamos lidando com cluster de servidores JBoss AS 7, que pode possuir N servidores, que também são chamados de instâncias do cluster. O loadbalance, através de critérios configurados, toma a decisão de chamar uma determinada instância do cluster para ATENDER a requisição HTTP. Um dos critérios usados, é verificar qual instância do cluster de JBoss AS 7 está ativa no momento e com menos carga. Localizado a instância, a requisição é direcionada para ela. E também, se algumas instâncias deixaram de funcionar, o loadbalance direciona as requisições para as instâncias ativas. Para isso, o loadbalance também conta com mecanismo para verificar se as instâncias estão vivas no momento, pois não faz sentido redirecionar requisições para instâncias mortas.

Veja no desenho abaixo como que funciona um cluster de instâncias do JBoss AS com o loadbalance (Apache WebService + mod_cluster).






CONFIGURAÇÃO DE CADA NODO DO JBOSS AS 7.1.3

1 – Copie as pastas do servidor JBOSS AS 7.1.3 e renomeie cada cópia para:

jboss-as-7.1.3.Final-node1
jboss-as-7.1.3.Final-node2
jboss-as-7.1.3.Final-node3

Cada pasta será uma instância do servidor JBoss AS 7 e funcionará no modo STANDALONE.

Para cada cópia, alterar o arquivo standalone.conf que está na pasta “bin” dentro de cada instância colocando os seguintes parâmetros:

JAVA_OPTS="$JAVA_OPTS -Djboss.server.default.config=standalone-full-ha.xml"
JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.as.logging.per-deployment=false"
# Esse offset deve ser diferente para cada nodo.
JAVA_OPTS="$JAVA_OPTS -Djboss.socket.binding.port-offset=1000"
# O nome do nodo deve ser diferente para cada nodo.
JAVA_OPTS="$JAVA_OPTS -Djboss.node.name=nodo1"

Lembrando que para cada instância, teremos o parâmetros “-Djboss.node.name” e “-Djboss.socket.binding.port-offset” diferentes.

Podemos usar os seguintes valores para cada instância:

Instância
-Djboss.socket.binding.port-offset
-Djboss.node.name
jboss-as-7.1.3.Final-node1
1000
nodo1
jboss-as-7.1.3.Final-node2
2000
nodo2
jboss-as-7.1.3.Final-node3
3000
nodo3


Arquivo standalone-full-ha.xml

Também, precisamos alterar o arquivo “standalone-full-ha.xml” para cada instância do cluster de acordo com as configurações a seguir:

Na tag “server”, colocar o atributo name com o nome da instância. Lembrando que esse nome deve ser único entre as instâncias do cluster.

Instância
Tag “server”, atributo “name”
jboss-as-7.1.3.Final-node1
<server name="standalone-nodo-1" xmlns="urn:jboss:domain:1.3">
jboss-as-7.1.3.Final-node2
<server name="standalone-nodo-2" xmlns="urn:jboss:domain:1.3">
jboss-as-7.1.3.Final-node3
<server name="standalone-nodo-3" xmlns="urn:jboss:domain:1.3">

Dentro da tag “server” colocar a seguinte tag para todas as instâncias do cluster.

<system-properties>
<property name="org.apache.tomcat.util.http.Parameters.MAX_COUNT" value="5000"/>
</system-properties>

Essa propriedade define o tamanho máximo de uma requisição HTTP. Se não definir esse tamanho, ao fazer uma requisição HTTP com muitos parâmetros na url, a instância que tratará a requisição, poderá lançar exceção com erro 500.

Dentro da tag “cache-container” colocar o seguinte atributo para iniciar o cache no inicio do servidor.

start="EAGER"

Existe um bug no JBoss AS 7.1.x que não inicia o cluster corretamente no infinispan (gerenciador de cache distribuído do JBoss AS 7.x). Para contornar esse problema, temos que iniciar todos os caches de forma “EAGER” (carrega tudo no inicio) e não “LAZY” (padrão, carrega só quando o cache for de fato chamado por alguma aplicação).

No subsistema web, mudar a tag para:

<subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" instance-id="${jboss.node.name}" native="false">

Note que essa tag vai informar o nome do servidor configurado acima.

Configurar as interfaces com o código abaixo:

<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:0.0.0.0}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
</interface>
<!-- TODO - only show this if the jacorb subsystem is added -->
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:0.0.0.0}"/>
</interface>
</interfaces>

Na tag “socket-binding-group”, alterar para as seguintes configurações de acordo com a instância usada.

Instância
Tag “socket-binding-group”
jboss-as-7.1.3.Final-node1
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:1000}">
jboss-as-7.1.3.Final-node2
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:2000}">
jboss-as-7.1.3.Final-node3
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:3000}">


No subsistema modcluster, mudar a tag para:

<subsystem xmlns="urn:jboss:domain:modcluster:1.1">
  <mod-cluster-config advertise-socket="modcluster" connector="ajp"
proxy-list="127.0.0.1:6666">
            <dynamic-load-provider history="10" decay="2">
        <load-metric type="cpu" weight="2" capacity="1"/>
        <load-metric type="sessions" weight="1" capacity="512"/>
    </dynamic-load-provider>
            </mod-cluster-config>
        </subsystem>


Muito importante configurar o atributo “proxy-list” para o servidor de IP 127.0.0.1 (local) na porta 6666. Esse valor é configurado também no arquivo httpd.conf do Apache Web Server (httpd). Se não configurar isso, a instância do JBoss pode não localizar o httpd e este último, não conseguir fazer os redirecionamentos e começar a lançar os erros 404, “not found”, não localizado.

No subsistema de logging, acrescente o seguinte bloco para fazer log no modcluster para debug.

<logger category="org.jboss.modcluster">
<level name="INFO"/>
</logger>



Arquivo nodo.sh

Esse arquivo será criado para iniciar cada instância do cluster. Veja abaixo:

./standalone.sh -c standalone-full-ha.xml -b 127.0.0.1 -u 230.0.0.4 &

Para funcionar o cluster com JGroups, o parâmetro b não pode ser configurado com “0.0.0.0”, deve ser atribuído endereço IP da máquina que está rodando o JBoss AS 7. Caso esteja rodando tudo local, use “127.0.0.1”.

O “&” (E comercial) serve para desvincular a execução do comando do prompt, assim, mesmo que o console seja fechado, o servidor continua ativo. Para desligar o servidor, precisa-se executar esses comandos:

ps aux | grep “jboss”

Para localizar o processo com o nome “jboss”.

kill -TERM pid

Para enviar uma mensagem para finalizar o processo, nesse caso, o servidor JBoss AS 7. A variável “pid” é o número do processo obtido na execução do comando anterior.

Ou para desligar de vez (definitivamente) o servidor JBoss AS 7, digite

kill -9 pid


Depois disso, copie esse arquivo para cada pasta “bin” de cada instância do JBoss AS 7.
Dê permissão de execução para esse arquivo “.sh”, com o comando abaixo:

chmod a+x nodo.sh



CONFIGURAÇÃO DO JBOSS MOD_CLUSTER (LOADBALANCE).

1 – Download do binário no site http://www.jboss.org/mod_cluster
na versão 1.1.x. A última versão até a escrita desse é artigo é a versão 1.1.3. Na documentação do JBoss AS 7, o site www.jboss.org deixa bem claro que deve ser usado o mod_cluster na versão 1.1.x. Se utilizar outra versão, pode ser que não funcione.
Lembrando também de baixar a versão para a plataforma alvo correta. Para escrever esse artigo, usamos o sistema operacional Linux 32 bit. E também, baixar o mod_cluster “completo”, no sentido de estar junto com Apache Web Server, chamado também de “httpd”. Pois o mod_cluster do JBoss é uma extensão (módulo) do httpd para trabalhar com cluster de JBoss AS's. Se baixar somente os módulos, deverá copiar os arquivos binários “.so” (linux) ou “.dll” (windows) para os diretórios de módulos do httpd e ainda, configurar o arquivo “httpd.conf”(que será usado a seguir). Mais detalhes da configuração do httpd, entre no site http://httpd.apache.org/docs/2.2/
Mas nesse artigo, usaremos a versão já empacotada do mod_cluster com o httpd.

2 – Descompactar arquivo “mod_cluster-1.1.3.Final-linux2-x86-ssl.tar.gz” com o comando:

tar xvfz mod_cluster-1.1.3.Final-linux2-x86-ssl.tar.gz

3 – Copiar o diretório "opt/jboss" para o diretório "/opt". Para isso, precisa-se usar o superusuário. 

Diretório aonde descompactou o arquivo “tar.gz”.
Entre no diretório “opt” criado, comando:

cd opt

Comando para cópia:

sudo cp -R jboss /opt

4 – Edite o arquivo httpd.conf localizado no diretório “/opt/jboss/httpd/httpd/conf”.
Procure a linha “ServerName” e descomente essa linha.
Mude “www.example.com:80” para “127.0.0.1:80”. Lembrando que a porta “80” é porta que será usada para receber requisições HTTP e apartir daí, o httpd com o mod_cluster (JBoss) delegará a requisição para a instância do JBoss AS 7 que cumprir os critérios do loadbalance (dentro do mod_cluster). Lembrando também que o endereço IP “127.0.0.1” pode ser alterado para o endereço IP da máquina atual.

5 – Criar os scripts para iniciar e parar o Apache Web Server com o mod_cluster.
O nosso loadbalance conforme explicado anteriormente, funciona como um módulo (extensão) do Apache Web Server, então criaremos scripts para iniciar e parar esse servidor (httpd).

// Script para inicio do Apache Web Server.
// Coloque o nome de “httpd_start.sh
// Dê permissão de execução com o comando:

chmod a+x httpd_start.sh

// Cole o conteúdo abaixo no arquivo “httpd_start.sh”.
/opt/jboss/httpd/sbin/apachectl start &

// De forma análoga, vamos criar o arquivo “httpd_stop.sh
// para parar o servidor httpd.
// Dê permissão de execução com o comando:

chmod a+x httpd_stop.sh

// Cole o conteúdo abaixo no arquivo “httpd_stop.sh”.
/opt/jboss/httpd/sbin/apachectl stop &

6 – Inicie o servidor Apache Web Server (httpd) com o comando
sudo ./httpd_start.sh

// Lembrando que para usar a porta 80 precisamos de acesso root ao sistema operacional.
7 – Entre em qualquer navedor web (firefox, chrome, etc) e acesse o endereço:


Deverá aparecer a seguinte mensagem:

It works!”

Está trabalho, ativo.


RODANDO UMA APLICAÇÃO WEB SIMPLES

Com o loadbalance (mod_cluster) e as instâncias configuradas, precisamos criar uma aplicação web simples e fazer a sua implantação (deploy) em cada instância do JBoss AS 7. Para isso, vamos criar o servlet “LoadBalanceServlet” cujo código será mostrado a seguir:

Arquivo “LoadBalanceServlet.java”

package test;

import java.io.IOException;
import java.util.Calendar;
import java.util.Enumeration;
import java.util.Properties;

import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
* Servlet implementation class LoadBalanceServlet
*/
@WebServlet("/LoadBalanceServlet")
public class LoadBalanceServlet extends HttpServlet {
private static final long serialVersionUID = 1L;

/**
* @see HttpServlet#HttpServlet()
*/
public LoadBalanceServlet() {
super();
// TODO Auto-generated constructor stub
}

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
ServletOutputStream out = response.getOutputStream();
response.setContentType("text/html");

out.println("<html>");
out.println("<head>");
out.println("<title>" + "Teste loadbalance - Host "
+ request.getRemoteAddr());
out.println("</title>");
out.println("</head>");
out.println("<body>");
out.println("Nodo do JBOSS chamado: ");
out.println("jboss.node.name: "
+ System.getProperty("jboss.node.name"));
out.println("Tempo: " + Calendar.getInstance().getTimeInMillis());

out.println("</body>");
out.println("</html>");

out.close();
out.flush();
}

/**
* @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse
* response)
*/
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
doGet(request, response);
}
}


A seguir será mostrado o código do arquivo web.xml contendo a configuração do Servlet.

xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
<display-name>LoadBalanceTestWAR</display-name>
<distributable/>
<servlet>
<servlet-name>LoadBalance</servlet-name>
<servlet-class>test.LoadBalanceServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>LoadBalance</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>

Com essa configuração, basta acessar o servlet pelo seguinte endereço:
<


Também precisamos do arquivo “jboss-deployment-structure.xml” para fazer o deploy da aplicação web.


Arquivo “jboss-deployment-structure.xml

xml version="1.0" encoding="UTF-8"?>

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<dependencies>
<module name="javax.api" />
</dependencies>
</deployment>
</jboss-deployment-structure>

Todos esses arquivos “.xml” devem estar na pasta WEB-INF da aplicação web.

Como estamos usando a porta 80 que é padrão para o protocolo HTTP, podemos omitir a porta. Ao se fazer uma requisição para esse endereço, o mod_cluster de acordo com as políticas definidas, delegará a requisição para uma determinada instância do cluster de JBoss AS 7. Esse servlet deve criado e empacotado como um arquivo “LoadBalanceTestWAR.war”.

Para testar o loadbalance, faremos diversas requisições para o mesmo endereço (http://127.0.0.1/LoadBalanceTestWAR) diversas vezes, partindo de apenas um browser web ou diversos browsers web.

Nas figuras a seguir, serão mostradas duas chamadas para o mesmo endereço que foi processado por dois nodos diferentes. Para simular isso, basta clicar em atualizar diversas vezes, até mudar o texto da página para outro nodo do cluster.






CONCLUSÃO

Esse artigo mostrou todos os passos necessários para configurar um loadbalance sobre um cluster de JBoss AS 7. E também, podemos mudar as políticas envolvidas na seleção do nodo, como por exemplo:

  • O nodo que estiver mais inativo, isto é, quantidade de cpu usada menor, terá prioridade para receber requisições
  • O nodo que estiver usando menos memória heap da JVM, terá prioridade para receber requisições
  • O primeiro nodo localizado que estiver ativo terá prioridade de receber requisições.
  • O nodo será escolhido de forma aleatória e o escolhido, receberá a requisição.
  • O nodo que processou menos requisições no dia terá prioridade para receber requisições.
  • O nodo que processou uma requisição anterior do mesmo host de origem, terá prioridade para processar requisições.

Além dessas regras, podemos criar outras regras e combiná-las entre si, de acordo com as regras do negócio envolvidas. Basicamente, recebemos como ENTRADA a requisição e no fim, o loadbalance deverá retornar uma instância do cluster de JBoss AS 7 que deverá receber a requisição. Depois disso, o mod_cluster delega a requisição para o nodo escolhido. Esse processo se repete a cada requisição.
Portanto, para maior aprofundamento, precisa-se saber como configurar o mod_cluster para conter regras personalizadas e de acordo com o nosso negócio em questão.


REFERÊNCIAS

quarta-feira, 10 de abril de 2013

Configurando APR (JBoss Web Native) no JBoss AS 7.1.3


INTRODUÇÃO


Habilitando o uso do APR (Apache Portable Runtime), permite que o subsistema web do servidor JBoss AS 7 possa usar essa API que por sua vez, chama métodos nativos (JNI) da plataforma atual. Ou seja, se estamos usando linux, configuramos o servidor JBoss para "enxergar", "reconhecer" os arquivos binários ".so" que executará de maneira nativa no micro o que dará maior desempenho ao invés de usar o subsistema web no JBoss AS 7 totalmente em Java.
O Jboss fornece pacotes com binários para diversas plataformas, assim, podemos aumentar o desempenho do subsistema web para cada plataforma.


CONFIGURAÇÃO

Download do arquivo jbossweb-native-2.0.10.jar

Contêm todos binários de todas plataformas.

Descompacte esse arquivo.

Entre dentro da pasta que contêm o jbossweb-native descompactado e depois disso, entre na pasta "bin"

Copiar tudo o que contêm a pasta "bin" para dentro da pasta "bin" do servidor JBoss AS 7.1.

Exemplo:

// Supondo que essa pasta contêm
// os diretórios / arquivos do arquivo compactado jar.

cd jbossweb-native-2.0.10 

// Entra no diretório bin.
cd bin

// Copia de modo recursos todos os subdiretórios
cp -R META-INF $JBOSS_HOME/bin

// Entre no diretório $JBOSS_HOME/bin
cd $JBOSS_HOME/bin

// Veja se o diretório META-INF foi copiado dentro do diretório $JBOSS_HOME/bin
ls $JBOSS_HOME/bin.

// Execute o seguinte comando no diretório META-INF para
// que os arquivos binários (dll, so, etc, dependendo da plataforma) possam
// ser executados. Esse comando dará permissão de escrita.
chmod -R a+x META-INF

// Esse comando tem o argumento "-R" que indica recursividade, ou seja, o diretório META-INF
// e seus subdiretórios e arquivos, terão suas permissões alteradas de maneira recursiva, até achar diretórios folhas (sem filhos).
// Se não executar esse comando, os binários podem não ser carregados, pois o sistema operacional
// rejeitará o carregamento dos binários pela JVM.


Ajustar standalone-full-ha.xml:


Mude o valor do atributo "native" de "false" para "true".

<subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" instance-id="${jboss.node.name}" native="true">



Inicie o servidor JBoss AS 7.1.3.

Verifique no log ($JBOSS_HOME/standalone/log/server.log) se o APR está ativo.
Para isso, execute o seguinte comando:

cat server.log | grep "coyote"


O servidor deverá mostrar essas linhas:

09:41:37,492 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-1) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8009
09:41:37,519 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8080


Se não aparecer essas linhas, isso indica que as bibliotecas nativas do jboss-web native não foram instaladas com sucesso.


CONCLUSÃO

Com o uso do jboss web nativo, aumentamos o desempenho do servidor na parte web. E também, é importante lembrar que o uso dessas bibliotecas nativas (binários) é de uso opcional, não impactando no funcionamento correto do servidor e a única coisa que agrega, é mais desempenho, por usar componentes que são executados diretamente na máquina e não via JVM.
Lógico que o servidor JBoss AS 7 roda em cima de uma JVM, mas com o jboss web nativo ativado, o processamento passa da JVM pela interface JNI (interface para acesso de métodos nativos no Java) que invoca as implementações de métodos nativos nos binários da plataforma.


REFERÊNCIAS