[RESUELTO] invoker: No puedo reservar espacio para instancia de servlet para trayectoria /servlet/

Si te aparece este mensaje en el log del JBoss

"Cannot allocate servlet instance for path /examples/servlet/server"
"No puedo reservar espacio para instancia de servlet para trayectoria /servlet/"

LOG:

2015-09-03 14:55:56,857 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] (main) JBoss (Microcontainer) [5.1.0 (build: SVNTag=JBPAPP_5_1_0 date=201009150028)] Started in 3m:1s:90ms
2015-09-03 15:00:03,653 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[ ].[/]] (ajp-192.168.250.120-8009-1) Marcando el servlet org.apache.catalina.INVOKER. como no disponible
2015-09-03 15:00:03,655 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[ ].[/]] (ajp-192.168.250.120-8009-1) invoker: No puedo reservar espacio para instancia de servlet para trayectoria /servlet/
javax.servlet.ServletException: Error instanciando clase de servlet
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1022)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:777)
at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:361)
at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134)


Es porque el war no ha generado las clases en la carpeta /classes/ del mismo war.

Para corregirlo ubiquese en Project/Properties/Java Build Path/Order and Export/ y asegurese que primero se encuentre el JRE (java)

Afinamiento del Garbage Collector para JBoss

Previamente a realizar cualquier cambio en la elección del garbage collector, ejecuta tu aplicación y deja que la JVM seleccione el collector mas adecuado, si es necesario redimensiona el Heap para mejorar el rendimiento. Si el desempeño no cumple tus objetivos realiza lo siguiente pasos:

1. Si la aplicación mantiene pequeños conjuntos de datos usa serial collector, habilítalo con: -XX:+UseSerialGC

2. Si la aplicación se ejecuta en un solo cpu y no tiene requerimientos de pausa por GC
· Deja que la JVM seleccione el collector
· Selecciona el serial collector –XX:+UseSerialGC

3. Si a) Si el máximo rendimiento es tu primera prioridad y b) no hay requerimientos de pausa o las pausas son de un segundo o mas pero aceptables
· Deja que la JVM selección el collector
· Selecciona el parallel collector con –XX:+UseParallelGC y opcionalmente habilita el parallel compaction con –XX:
+UseParallelOldGC

4. Si el tiempo de respuesta es más importante que el throuhgput y las pausas del garbage collection son cortas.
· Selecciona concurrent collector con –XX:+UseConcMarkSweepGC

Afinamiento de la JVM para JBoss

En las versiones mas recientes de la Sun Java Virtual Machine – JVM denominada también “HotSpot”, se ha implementado mejoras en dos aspectos importantes como son el proceso de garbage collector y en la parametrizacion de los pools de memoria que usan las aplicaciones denominado HEAP.

La configuración por defecto de la JVM normalmente es adecuada para iniciar un periodo de observación del comportamiento de las aplicaciones, si la elección de los parámetros por defecto no satisface los requerimientos entonces es posible realizar ciertas tareas de afinamiento de la JVM para mejorar el  desempeño de las aplicaciones.

Generaciones

El Heap, la memoria utilizada por la JVM para almacenar los datos se distribuye en los siguientes pools:



Se divide el Heap partiendo de la hipótesis de que gran parte de los objetos reside un corto tiempo en el heap. El Eden es el área donde se crean los nuevos objetos, el área de Survivor es el área donde se reciclan los objetos intermedios, el área Virtual es una área de reserva para el crecimiento del pool, en total existen dos áreas de Survivor y siempre uno debe estar disponible. El Tenured es un pool donde se almacenan los objetos mas antiguos, y el área permanente (Perm) es donde residen los objetos que estarán siempre o permanentemente en la memoria como son los datos necesarios para la operación de la JVM y aquellos que describen clases y métodos. La generación young, esta conformada por el Eden y los dos espacios de survivor

Garbage Collection

Muchos de los objetos “mueren jóvenes”, es decir en el la generación young, esto se representa en la figura 2, cuando el young esta lleno se produce un garbage Collection llamado minor Collection, que elimina de la memoria todos los objetos de la generacion young que ya no son alcanzables por ningun puntero de alguna aplicación que se este
ejecutando. En un ciclo tipico de minor Collection una fraccion de los objetos que residen en el young son movidos al tenured. Cuando el tenured se llena ocurre un major collection que resulta en una recoleccion de objetos inalcanzables de todo el head, un minor Collection normalmente es mucho mas rapido que un major Collection que hace
un barrido de todo el pool de heap.



Medidas de Desempeño del Garbage Collection

Las siguiente son medidas de desempeño a tener en cuanta:

Throughput: es el porcentaje del total de tiempo que no se hace garbage collection sobre periodos largos de tiempo. El throughput incluye el tiempo gastado en hacer asignaciones.

Pausas: son las veces que la aplicación parece no responder porque el garbage collection esta ocurriendo.

Footprint: es el trabajo conjunto de un proceso, medido en caché de páginas y líneas

Promptness: es el tiempo transcurrido entre que el objeto será desalojado (muere) y cuando se disponga de la memoria

Las medidas más importantes son las dos primeras y sirven para priorizar objetivos.

Garbage Collector Disponibles

Serial Collector

Usa un solo thread para el proceso de garbage collection, es ideal para maquinas con un solo cpu. Para maquinas con mas de un cpu es conveniente cuando se mantiene un conjunto pequeño de datos aproximadamente menor a 100 MB.

Se selecciona por defecto en ciertas plataformas pero se puede habilitar con
–XX:+UserSerialGC.

Parallel Colector

Ejecuta los minor collection en paralelo, para los major collection usa un solo thread presenta un mejor desempeño en maquinas con varios cpu, es ideal para aplicaciones que mantienen medianos o grandes conjuntos de datos. En sistemas operativos multithread con jdk 5.0 se selecciona por defecto sin embargo se puede seleccionar explícitamente con: –XX:+UseParallelGC

En J2SDK 5.0 fue introducida la característica de parallel compaction, esta permite ejecutar los procesos major collection en paralelo. Se habilita con la opcion:
-XX:+UseParallelOldGC

En maquinas con N cpus, el parallel collector usa N threads, el numero de garbage collector threads puede controlarse con: -XX:ParallelGCThreads=<N>

En maquinas con un solo cpu, el serial collector podría ser mejor por el overhead que cusa la sincronización de los threads en paralelo, cuando se usa el parallel collector con un solo cpu.

Concurrent Collector

Ejecuta el trabajo del garbage collection concurrentemente con la aplicación para tener pausas cortas de garbage collection. Se usa en aplicaciones que mantienen medianos o grandes conjuntos de datos. Es conveniente cuando el tiempo de respuesta es mas importante que el throughput en general (esta técnica puede reducir el desempeño de la aplicación). Se habilita con –XX:+UseConcMarkSweepGC

Afinamiento de la Memoria de Linux para JBoss

Parámetro shmmax

El parámetro shmmax es usado para definir el tamaño máximo en (bytes) para el segmento de memoria compartida. Es conveniente incrementarlo para aplicaciones que usen grandes cantidades de memoria. Se recomienda definirlo en 2GB por defecto en algunas distribuciones de RedHat Linux es de 32MB. Tener presente que el tamaño máximo de este parámetro es de 4GB.

Hugepages

Hugepages puede potencialmente proveer un alto desempeño a partir del hardware reduciendo el uso del cache del CPU. Los beneficios generalmente lo obtienen las aplicaciones que usan cantidades grandes de memoria para almacenar sus datos. Para que las aplicaciones puedan explotar esta opción, la característica de Hugepages debe ser soportada por el sistema operativo.

Para descubrir si el kernel soporta Hugepages, ejecuta:

[root@localhost ~]# grep Huge /proc/meminfo
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 4096 kB
[root@localhost ~]#

Para hacer que el HEAP use una huge page de al menos 2GB, podemos configurar los parámetros anteriormente descritos de la siguiente manera:

Configura shmmax dinámicamente mediante:

#echo 2147483647 > /proc/sys/kernel/shmmax

O puedes setearlo en el archivo /etc/sysctl.conf, agregando la siguiente linea:

kernel.shmmax = 2147483647

Configura el parámetro nr_hugepages a 1000 dinámicamente, ejecutando el siguiente comando:

#echo 1000 > /proc/sys/vm/nr_hugepages

O agrega el en el archive /etc/sysctl.conf la siguiente linea:

vm.nr_hugepages = 1000

En las opciones de la JVM de Sun agrega la siguiente opción: XX:+UseLargePages

Es necesario que reinicies el sistema para asignar las “Hugepages”, porque las Hugepages requieren grandes áreas de memoria física contigua, es decir la memoria física debe ser mapeada a las páginas que la requieran. Es recomendable configurar estos parámetros en el archivo /etc/sysctl.conf para asignar la Hugepages en  tiempo de inicio del sistema.

Afinamiento de IO de Linux para JBoss

Parametro tcp_keepalive_intvl

La variable tcp_keepalive_intvl le dice al kernel cuánto tiempo es la espera de una respuesta en cada KeepAlive. Este valor muy importante cuando se intenta calcular cuánto tiempo pasará antes de que una conexión se de por “muerta”.

La variable tiene un valor por defecto de 75 segundos. Los valores por defecto de tcp_keepalive_probes y tcp_keepalive_intvl pueden ser utilizados para obtener el valor por defecto que tomará de tiempo antes de que la conexión se de por perdida.

Con los valores por defecto de envío de 9 paquetes con 75 segundos para cada uno, que se tardaría aproximadamente 11 minutos antes de la conexión agote el tiempo, contando a partir del momento en que se inicie el sondeo puede pasar 2 horas desde la última vez que se vio tráfico en la conexión, este tiempo esta controlado por el parámetro tcp_keepalive_time que tiene un valor por defecto de 7200 (2 horas) segundos no se recomienda disminuirlo para evitar trafico en la red.

Se recomienda 15 segundos en este parámetro, para cambiarlo ejecuta el siguiente comando:

[root@localhost ~]# echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl

Parametro tcp_keepalive_probes

La variable tcp_keepalive_probes le dice al kernel cuántos KeepAlive TCP hay que enviar antes de que decida dar por terminada una conexión rota.

Esta variable tiene un valor, que en general no debe ser superior a 50. El valor por defecto es 9, antes de decirle a la aplicación que se ha interrumpido la conexión.

Se recomienda 5 intentos de valor en este parámetro, para cambiarlo ejecuta el siguiente comando:

[root@localhost ~]# echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

Afinamiento del Kernel de Linux para JBoss

JBoss AS y la Java Virtual Machine pueden alcanzar un mejor desempeño en un sistema operativo afinado. En un entorno como Linux, es necesario ajustar algunos parámetros del kernel para tal fin.

Parametro file-max

El Parámetro file-max /proc/sys/fs/file-max, define el máximo numero de archivos que el kernel de Linux puede manejar. Este parámetro generalmente se afina para mejorar el manejo de archivos, incrementando el valor de /proc/sys/fs/file-max a un valor razonable como 256 por cada 4 MB de RAM. Ejemplo: para un servidor con 128 MB de RAM, asigna el valor 8192. Resultado de 128/4=32; 32*256=8192.

Para visualizar el valor por defecto ejecuta el comando:

#cat /proc/sys/fs/file-max

Para ajustar el valor para un servidor con 1GB de RAM, realiza los siguientes pasos desde una consola o terminal:

# echo "65536" >/proc/sys/fs/file-max

Para que no tengas que tipear otra vez el comando anterior después de reiniciar el servidor, configure el file-max en el archive sysctl.conf, sigue los pasos indicados:

Edita el archivo /etc/sysctl.conf y agrega la siguiente línea:
fs.file-max = 8192

Reinicia el servidor o el servicio de red, para que los cambio tengan efecto.
#service network restart

Parametro ulimit

Linux tiene un límite máximo de procesos por usuario. Esta característica nos permite controlar el número de procesos que un usuario puede tener en el servidor.

Para proveer mas desempeño, podemos configurar el límite de procesos para el súper usuario root a ilimitado. Edita el archivo .bashrc con vi /root/.bashrc y agrega la siguiente línea:

-u unlimited

Para que tenga efecto el cambio, cierra la sesión y reingresa al sistema como root

Para ver todos los limites que puedes imponer, ejecuta ulimit –a.

[root@localhost ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16384
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@localhost ~]#

Incrementa el limite de sistema que determina los archivos abiertos que pueden haber por instancia de un proceso en RedHat. Incrementa el valor de este limite en la sesión actual que ejecuta JBoss al valor recomendado de 8000, usando el comando:

[root@localhost ~]# ulimit -n 8000

Para confirmar ejecuta el siguiente comando:

[root@localhost ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16384
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 8000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@localhost ~]#

java.lang.LinkageError: loader constraint violation - javax/xml/namespace/QName

Hace poco me salio este error en el JBoss 5.1 al desplegar una nueva aplicacion:

Servlet.service() para servlet appServlet lanzó excepción
java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.apache.axis.message.MessageElement.getChildElements(Ljavax/xml/namespace/QName;)Ljava/util/Iterator;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/apache/axis/message/MessageElement, and the class loader (instance of ) for interface javax/xml/soap/SOAPElement have different Class objects for the type javax/xml/namespace/QName used in the signature
at org.apache.axis.client.Call.invoke(Call.java:2364)
at org.apache.axis.client.Call.invoke(Call.java:1812)

Con JBOSS_HOME: \java\jboss-eap-5.1\jboss-as y JAVA: \java\jdk1.6\bin\java

Se trata que la clase javax.xml.namespace.QName se encuentra repetido en varios JAR de JBOSS+aplicacion+JAVA.

Buscando en la aplicacion encontre que javax.xml.namespace.QName estaba en jaxrpc.jar
Buscando en el JBOSS encontre que javax.xml.namespace.QName estaba en \jboss-as\lib\endorsed\stax-api-1.0.jar
Buscando en el JAVA encontre que javax.xml.namespace.QName estaba en \java\jdk1.6\jre\lib\rt.jar

La solucion fue borrar el stax-api-1.0.jar de la carpeta endorsed y borrar el javax.xml.namespace.QName.class de JAR jaxrpc.jar y asi que la aplicacion cargaba un jaxrpc.jar modificado manualmente.

Failed to load users/passwords/role files

Me salia este mensaje en el JBOSS y despues de probar varias alternativas finalmente di con la solucion.

El java donde estaba definido el webservice tenia este import

"import javax.ejb.Remote;"

Aunque compilaba bien, era innecesario (The import is never used) y motivo del conflicto.

Me olvidaba tambien cambie la clase SecurityDomain como lo que sigue:

//import org.jboss.annotation.security.SecurityDomain;
import org.jboss.ejb3.annotation.SecurityDomain;

Compile de nuevo y ya no salio la traza siguiente:

---------------- TRAZA DEL ERROR ----------------
ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http- ) Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:201)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:756)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:553)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:487)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160)
at org.jboss.web.tomcat.security.JBossWebRealm.authenticate(JBossWebRealm.java:399)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
... (etc)

Como acceder al Admin Console para monitorear JBoss EAP 5.0 (pantallas)

Como acceder al JMX Console (pantallas)

Instalacion y configuracion de JBoss EAP 5.0 (pantallas)

El JNDI View - datastore en JBoss EAP 5.0. - jmx-console y admin-console

Seguridad en JBoss EAP 5.0. Autenticacion, SSL, JAAS, LDAP

El servidor de aplicaciones puede usar las librerías del JBoss para autenticar al usuario, configurando donde se guardan las credenciales (una base datos o un directorio de usuarios o un archivo plano)

La seguridad en JBoss es declarativa por lo que declara en archivos XML antes que incluirlos en los componentes de negocio. La seguridad no se programa.

La autenticacion asigna la identidad del usuario. La autorizacion  asigna  permisos sobre los  recursos.

Para la autenticación el JBoss ha desarrollado varios modulos:

En el archivo /conf/login-config.xml se definen las políticas de autenticación.

<application-police>
<module />

</application-police>

El JBoss cuenta con una implementación estándar de la especificación JAAS (Java Autentication and Authorization Service). Todos los servidores de aplicaciones cuentan con una implementación de JAAS.

Los roles JBoss tienen accesos a componentes JSP o servlets, también se puede brindar accesos a un botón o un método. Los roles se les asigna a un grupo de usuarios.

En la aplicación se agrega un archivo jboss-web.xml para definir la política de autenticación. En login-config.xml se indica la política configurada en el jboss-web.xml de la aplicación. Los componentes EJB se configuran con el archivo ejb-jar.xml.

Se puede configurar  multiples dominios de seguridad, uno diferente para cada aplicación. Pero con un único dominio de seguridad, un usuario validado en una aplicación  puede conectarse a otra aplicación. Un dominio de seguridad tiene asociado un nombre único.

El LoginModule es la implementación de la autenticación del usuario y password, usualmente contra algún tipo de almacemiento de datos. El LoginModule asigna roles. Se configura un LoginModule por dominio de seguridad. El DatabaseServerLoginModule accede a una base de datos para autenticar el usuario y el password. Otro método de autenticación es usar un LDAP server.

En JBoss tambien se puede asegurar el acceso a los EJB, a las colas de mensajeria, y también los datasource.

Para asignar roles a un EJB se usa el descriptor de los componentes ejb-jar.xml  y también a través del mismo componente via anotaciones.

El SSL se configura en el deploy/jbossweb.sar/server.xml. El certificado se configura en el archivo jboss-web.xml. La seguridad JAAS también se puede acceder via JNDI.

El método de autenticación en JBoss para el login son: basic (formulario estandar del jboss), form (formulario definido por el programador), cert (con certificado digital), digest (con protocolo SSL).

 

Como aligerar los servicios del JBoss EAP 5.0

Se debe quitar del JBoss los elementos que no se van a usar. El aligeramiento se inicia con la configuracion "default" sino esta en cluster y con "all" si esta en cluster. La configuracion "production" tiene lo minimo, ni aparace el log en la consola. El estado de los parametros del servidor se pueden observar en el jmx-console.

Si se carga el mail al JBoss, en la consola se mostrará: [MailService] Mail Service bound to java:/Mail.

Si no se desea cargar el mail al JBoss se remueve el archivo mail-service.xml de la carpeta deploy y el JBoss informara:   [MailService] Mail service 'java:/Mail' removed from JNDI.

Para deshabilitar el conector AJP, se modifica en \deploy\jbossweb.sar comentando lo siguiente.

<!-- A AJP 1.3 Connector on port 8009

      <Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"

         redirectPort="8443" />

 -->

Para deshabilitar el servicio Messaging del JBoss se remueve la carpeta \deploy\messaging

Para deshabilitar el servicio Transaction del JBoss se remueve el archivo /deploy/transaction-service.xml

JNDI, mensajes y colas en JBoss EAP 5.0

El servicio JNDI se configura en el archivo conf/jboss-service.xml. Un servidor JBoss puede utilizar HTTP o HTTPS. En ambientes en cluster el JNDI puede estar disponible mediante HA-JNDI. Se conecta con la IP ${jboss.bind.address} que se muestra en los archivos de configuración.

En el servidor, el servicio JNDI se configura en el conf/jboss-service.xml. El JNDI naming service se configura mediante el archivo  jndi.properties en el cliente.

EL JNDI usa el puerto 1099. En JBoss se hace un tunel para acceder al servicio de manera remota (puede cruzar un firewall).

Properties p = new Properties();

p.put("java.naming.provider.url","...");

Context ctx = net Context(p)

Impuesto i =  (Impuesto) ctx.lookup("interes/remote");

double d = i.getInteres(8.2);

Otro servicio que provee JBoss es el servicio de mensajería que se maneja mediante colas. Los mensajes se utilizan entre aplicaciones generalmente mediante procesos asíncronos. La mensajería se usa cuando se tiene un sistema con alta demanda.

Las colas están configuradas en el  deploy/messaging/messaging-services.xml y en destination-services.xml. Otro archivo importante es *-persistente-service.xml si se desea que las colas se guarden en una base de datos. Para agregar o modificar una cola en JBoss se configura el archivo  deploy/messaging/destination-services.xml

Otros conectores que JBoss maneja son: remoting, RMI/JRMP. Permite acceder a los componentes EJB a través del puerto 4445. También permite realizar pedidos remotos vía sockets.

Como configurar varios nodos JBoss con la misma IP y diferente puerto?

El servicio ServiceBindingManager permite levantar varios nodos en el mismo hardware y con la misma IP. Si en el archivo de configuración, el offset es igual a 100 y el port del jboss es 8080, el port1 será 8180, el port2 será el 8280. De esta manera se levanta varios JBoss con la misma IP y diferente puertos

Para levantar cada uno de los nodos se realiza:

run.bat -c nodo1  -Djboss.service.binding.set=port1

run.bat -c nodo2  -Djboss.service.binding.set=port2

run.bat -c nodo3  -Djboss.service.binding.set=port3

No se recomienda usar el ServiceBindingmanager sobre direcciones virtuales, mucho mejor se realiza sobre IPs reales.

HTTP, HTTPS y AJP en JBoss Web Server EAP 5.0

La capa web se conoce como JBoss Web Server (jsp, jdni, webservice, servlets) y se puede licenciar por separado del JBoss EAP. Se basa en Apache-Tomcat. Soporta SSL. Puede balancear la carga mediante un Apache.

Los conectores web son HTTP1.1 (8080),  HTTPS (8443) y AJP1.3 (8009, Apache Java Protocol), este último se usa para conectarse a un balanceador de carga como Apache.

El servidor web de JBoss esta ubicado en la carpeta deploy/jbossweb.sar y la configuración del servidor esta en el archivo  deploy/jbossweb.sar/server.xml

Un Web Server como Apache se comunica con un Web Container como el JBoss mediante el protocolo AJP.

Los componentes web (JSP, servlets) se despliegan en un web container (Jboss Web).  Los componentes EBJ (session, entidad, MDB) se despliegan en un EJB container. Los componentes web se comunican con los componentes EJB  mediante el protocolo rmi.

Para que una plataforma diferente (como .NET) se comunique con el EJB container se requiere un WebService container que consuma los componentes del EJB container y lo tenga disponible para la otra plataforma.

El JBoss Web Engine puede contener multiples hosts. Un contexto en JBoss Web representa a una aplicacion web. Los tres principales conectores del JBoss Web son HTTP, HTTPS y AJP

El puerto pode defecto del AJP (Apache Java Protocol) es el 8009.  El JBoss Web Server se configura mediante el archivo /deploy/jbossweb.sar/server.xml

Como monitorear el JBoss EAP 5.0 JMX-console, admin-console

Las herramientas para monitorear el JBoss es el JMX-console, el admin-console, los logs del JBoss logging y el JBoss Operation Network.

Las 3 herramientas básicas para monitorear JBoss EAP son: jmx-console, admin-console y los logs del jboss ubicados en la carpeta /log

La tecnologia java que permite el monitoreo en tiempo real es el JMX.

Para acceder a la consola JMX en forma remota se debe configurar el archivo /bin/run.conf.bat

El JMX-console provee información sobre la performance y consumo de recursos de una aplicación accediendo a la JVM. El JMX-console cambia atributos en tiempo real.

Para proteger las consolas jmx-console y el admin-console en producción, se debe proteger el archivo de usuarios y passwords.

Para permitir el monitoreo mediante jconsole, se requiere modificar el archivo run.conf.bat que se encuentra en \jboss-as\bin

Se debe agregar debajo de los otros 3 JAVA_OPTS lo siguiente:

set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.platform.mbeanserver"

Se requiere reiniciar el JBoss para que tome estos parámetros.

Para acceder desde línea de comandos a la jmx-console se usa los comandos $jconsole o $jvisualm.

Para acceder remotamente al jconsole agregar las siguientes líneas en el run.conf.bat al final de los otros JAVA_OPTS

rem # Enable the jconsole agent remotely on port 12345
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=12345"
set "JAVA_OPTS=%$JAVA_OPTS% -Dcom.sun.management.jmxremote.authenticate=false"
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.ssl=false"

No olvidar comentar la línea

#set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.platform.mbeanserver"

Para que no tenga conflicto con la nueva configuración.

Al iniciar el $jconsole indicar en el parámetro "Remote Process"  la ip y el puerto del JBoss a monitorear como “10.10.10.85:12345”.

Para acceder al admin-console se realiza mediante http://127.0.0.1:8080/admin-console/.

Los parametros del datasource se pueden cambiar en caliente:

                <min-pool-size>1</min-pool-size>
                <max-pool-size>10</max-pool-size>

Una vez cambiadas las variables, estas se visualizan en la consola admin

Max Size             10           Max Size
Min Size              1             Min Size

Para una mejor performance de una configuración en producción, se debe remover el archivo hdscanner-jboss-beans.xml, que está en la carpeta deploy,  para que no se realice la revisión continua de parámetros. También se le puede colocar un  tiempo alto en la variable scanPeriod. Si el scanPeriod=5000 indica que cada 5 segundos revisara los cambios en la carpeta deploy. En producción elevar este valor a 5000000 o borrar el archivo hdscanner-jboss-beans.xml.

hdscanner-jboss-beans.xml

    <!-- Hotdeployment of applications -->

    <bean name="HDScanner" class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">

        <property name="deployer"><inject bean="ProfileServiceDeployer"/></property>

        <property name="profileService"><inject bean="ProfileService"/></property>

        <property name="scanPeriod">5000</property>

        <property name="scanThreadName">HDScanner</property>

    </bean>

JNDI View y el datasource en JBoss EAP 5.0.

Verificación mediante JNDIView de la configuración de un datasource en JBoss EAP 5.0.

Para verificar que el datasource este correcto, se verifica en el jmx-console. Mediante el http://127.0.0.1:8080/jmx-console/ se ubica la opción "service=JNDIView". Luego se utiliza la opción “list-xml” o “list” donde se observara que el datasource está configurado.

jb336DS
org.jboss.resource.adapter.jdbc.WrapperDataSource

Tambien se puede observar el datasource mediante el admin-console, donde se revisa la opción “Datasources”.

Conexión del JBoss EAP 5.0 con una base de datos.

Para que el JBoss se conecte con una Base de Datos se requiere un driver. El driver se obtiene de la pagina web de la base de datos en forma de *.jar. En el caso de MYSQL el driver se encuentra en  mysql-connector-java-5.1.6.jar.

Este conector se debe colocar preferiblemente en la carpeta de las librerías de la aplicación jboss-as/server/desarrollo/lib.  En la ruta \jboss-as\docs\examples\jca  se encuentran varios ejemplos de configuración de conectores a la base de datos. De esta carpeta obtenemos una plantilla llamada mysql-ds.xml (La plantilla mysql-xa-ds se utiliza para transacciones distribuidas o conexiones 2-phase-commit)

La plantilla mysql-ds.xml se copia en la carpeta  \jboss-as\server\jb336\deploy\  para renombrarlo como desarrollo-ds.xml  y configurarlo para nuestro entorno.

En el archivo desarrollo-ds.xml se configura la IP del servidor de datos, el usuario y password de conexión.

    <jndi-name>jb339DS</jndi-name>
    <connection-url>jdbc:mysql://10.10.10.10:3306/jbossdb</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>master</user-name>
    <password>password</password>

En el mismo archivo de configuración se agrega una sentencia para que el JBoss verifique que la conexión este vigente, el JBoss realizará el siguiente query:

    <check-valid-connection-sql>select 3</check-valid-connection-sql>

Las políticas de seguridad de la conexión se configuran en el archivo login-config.xml

  <application-policy name="eAplicacion">

    <authentication>

      <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required">

        <module-option name = "dsJndiName">java:/jb336DS</module-option>

                    <module-option name = "principalsQuery">SELECT PASSWORD FROM CUSTOMER WHERE USER_ID=?</module-option>

                    <!-- no roles are needed -->

                    <module-option name = "rolesQuery">SELECT null,null FROM CUSTOMER WHERE USER_ID=?</module-option>

      </login-module>

    </authentication>

  </application-policy>