BEA WebLogic Portal 10.2

BEA Virtualization - Welcome to the Java Next Level

JMX (Java Management Extensions) en WLS 8.1

Especifica estándares para automatizar la administración de dispositivos usando Java como lenguajes de control.
Desacopla la gestión de dispositivo de las herramientas de gestión.
El vendedor del dispositivo desarrolla “Management Beans” (MBeans) con su dispositivo. Asi los clientes pueden automatizar la gestión de dispositivos.

Un MBean es una construcción JMX que representa un recurso manejado. Cada recurso manejado en WLS usa MBeans para proporcionar una interfaz para monitorizar o modificar el recurso.

WLS MBeans suministra todas las operaciones estándar definidas en la especificación JMX, como:

• Constructores para instancias MBeans.
• Métodos para obtener y establecer los atributos de MBeans.
• Métodos para realizar operaciones adicionales especificas de MBeans.
• Notificaciones para eventos broadcast MBean.
  

WLS proporciona MBeans para administrar todos los aspectos del servidor de aplicaciones, como por ejemplo:

• Aplicaciones (Web, EJB,...)
• Seguridad.
• Dominios, servidores, cluster.
• Logs
• Servicios (JDBC, JMS, SNMP, XML)

Las herramientas de gestión WLS están implementadas en JMX:

• Consola de administración.
• Comando weblogic.Admin
• Comando weblogic.Deployer
• Herramientas de terceros

El Tipo de un MBean, es el nombre de la interfaz sin el sufijo MBean.

El Nombre de un MBean esta disponible cuando seleccionas el objeto de la consola (mira el atributo “Name”) o usando el comado weblogic.Admin GET –type tipo

Los Atributos en un MBean, revisa los métodos de acceso y elimina el prefijo “set” o “get”, o usa el comando weblogic.Admin GET

Sintaxis:
java weblogic.Admin [-url URL] [{-username username [-password password] } | {[-userconfigfile configfile] [-userkeyfile adminkey] } ] COMANDO argumentos

CONNECT – Hace el numero especificado de conexiones a WLS y devuelve el tiempo empleado.
FORCESHUTDOWN – Termina inmediatamente un proceso WLS.
GETSTATE – Devuelve el estado actual de WLS.
HELP – Proporciona ayuda de la sintaxis y uso de los comandos.
LICENSES – Lista las licencias para todas las instancias de WLS instaladas en un servidor especifico.
LIST – Lista los nodos del arbol JNDI.
MIGRATE – Migra un servicio JMS o JTA a un servidor objetivo del cluster.
PING – Envia un mensaje para comprobar que WLS esta escuchando en un puerto.
RESUME – Cambia al servidor de estado STANBY a RUNNING.
SERVERLOG – Muestra el fichero de log de un servidor especifico.
SHUTDOWN – Para un servidor.

Ejemplos:

java weblogic.Admin -url waswas.tsm.inet:30660 -username system -password T1f0n FORCESHUTDOWN MiServidor3

java weblogic.Admin HELP PING

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic THREAD_DUMP




Gestión de MBeans

CREATE – Crea un MBean de administración. Devuelve OK si tiene éxito.
DELETE – Borra un MBean. Devuelve OK a la salida estandar si tiene éxito.
GET – Muestra las propiedades de un MBean.
INVOKE – Invoca operaciones de gestión en MBean.
SET – Establece el valor a la propiedad especificada del MBean.


Todos los comandos de gestión de MBeans pueden aceptar el argumento –type, que opera sobre todos los MBeans del tipo especificado de la instancia.

java weblogic.Admin -username weblogic -password weblogic GET -type ServerRuntime -property State




Principales parámetros a monitorizar con JMX

ServerRuntime

• State, OpenSocketsCurrentCount

ExecuteQueueRuntime

• ExecuteThreadCurrentIdleCount, PendingRequestCurrentCount.

JVMRuntime

• HeapSizeCurrent

JDBCConnectionPoolRuntime

• ActiveConnectionsCurrentCount, ConnectionsHighCount, LeakedConnectionCount, ConnectionDelayTime, FailuresToReconnect

La utilidad weblogic.Deployer es una utilidad java que nos permite realizar tareas de despliegue.

Te permite desplegar una nueva aplicación, actualizar una aplicación existente, o undeploy una aplicación.

Para usar weblogic.Deployer:

• Establece tu entorno, para que las clases de WLS estén en tu classpath y JDK. Puedes usar del script setenv para establecer el classpath.

Sintaxis:

java weblogic.Deployer [ opciones ] [-deploy | -undeploy | -redeploy | -start | -stop | -listapps] [file (s)]

Desplegar una nueva aplicación:
java weblogic.Deployer –adminurl http://admin:7001 –name vflive –source /tmp/vflive.ear –targets server1,server2 –deploy

Redesplegar una aplicación:
java weblogic.Deployer –adminurl http://admin:7001 –name vflive –redeploy


Mas información

Configura tus Network Channels en WebLogic Server 8.1

En entornos de producción, a veces es necesario segregar el tráfico de red. WebLogic nos permite controlar este trafico de red asociado a nuestras aplicaciones

Para lo cual puedes especificar la NIC y los puertos usados por los servidores manejados, especificar entre múltiples protocolos, tamaño de mensajes …

Para lo cual puedes desde la consola Administrativa crearlo en Servers>Protocols>Channels o empleando el MBean NetworkAccessPoint directamente en el fichero de config.xml, si te sucede como nos sucedió en una ocasión en la cual no podíamos acceder a la consola administrativa de WLS 8.1 gracias a una “maravillosa” regla en un Firewall.

Para lo cual, lo que hicimos fue meter en el config.xml una línea como la siguiente:

Después de añadir esta línea en el config.xml, simplemente habría que reiniciar el servidor administrativo y ya estaría todo…. Mas fácil imposible ¡!!

Este articulillo me gustaría ofrecérselo a un administrador de weblogic que sostenía que esto de los Network Channels no existia y que eran “invenciones” mías, y dedicárselo a mi joven Padawan Pablo Yuste el cual creyó en mis enseñanzas y las defendió creyendo en mi palabra.

Tuning Java Virtual Machines (JVMs): Java Heap

Garbage collection es el proceso de la VM que recoloca objetos Java sin usar en la pila Java. La pila Java es donde están los objetos vivos de un programa java. Es un repositorio para objetos vivos, muertos y memoria libre. Cuando un objeto no puede ser referenciado por ningún puntero del programa en ejecución es considerado como basura

El tamaño de la pila de la JVM determina con que frecuencia y cuanto tiempo empleará la VM realizando recolección de basura. Un ratio aceptable para la recolección de basura de una aplicación debería ajustarse después de analizar el tiempo y la frecuencia con que se realizan los GC.

El objetivo de tunear el tamaño de la pila es minimizar la duración del GC, mientras maximizas el número de clientes que puede manejar en un momento dado.

En el Heap podemos distinguir 3 zonas:

• New o Young Generation: Los objetos inicialmente se situan aqui

Eden = NewSize – ((NewSize / (SurvivorRatio + 2)) * 2)
From Space = (NewSize – Eden / 2)
To Space = (NewSize – Eden) / 2)

-XX:NewSize
-XX:MaxNewSize
-XX:NewRatio
-XX:SurvivorRatio

• Old o Tenured Generation: Aqui encontraremos objetos con larga vida
  

-XX:OldSize -XX:MinHeapFreeRatio

-XX:MaxHeapFreeRatio

• Permanet Generation: Almacena clases de objetos
  

-XX:PermSize
-XX:MaxPermSize

-Xnoclassgc

Un objeto es basura cuando no puede ser alcanzado (no tiene referencias fuertes) desde ningún punto del programa que se está ejecutando. El método más directo de recolección de basura es iterar sobre cada objeto alcanzable, y se asume que todos aquellos por los que no se pase son basura. Este enfoque tarda un tiempo proporcional al número de objetos vivos, lo que es prohibitivo para grandes aplicaciones que mantienen gran cantidad de objetos vivos.

Versiones recientes de la JVM incorporan una serie de diferentes algoritmos de recolección de basura que se combinan utilizando la recolección generacional. Mientras la recolección ordinaria examina cada objeto vivo en el heap, la recolección generacional aprovecha ciertas propiedades de las aplicaciones observadas empíricamente para evitar trabajo extra.


La recolección de basura se produce en cada generación cuando ésta se llena. Los objetos se sitúan en el edén y, debido a la mortalidad infantil, la mayoría muere ahí. Cuando el edén se llena se produce una recolección menor en la que algunos objetos supervivientes se mueven a una generación más vieja. Cuando las generaciones viejas se llenan se produce una recolección mayor que, generalmente, es mucho más lenta debido a que involucra a todos los objetos vivos.

Cuanto más tiempo sobreviva un objeto, más recolecciones pasarán sobre él, y el recolector de basura se volverá más lento. La recolección de basura será más eficiente haciendo que los objetos no sobrevivan a la primera recolección. Las aplicaciones pueden trastornar esta situación ideal con distribuciones de tiempo de vida inusuales o con generaciones de tamaño pequeño que causan recolecciones con demasiada frecuencia.

Existen varias técnicas para desarrollar Garbage Collection. Las más utilizadas son marcar y barrer (mark-and-sweep) y recolección por copia (copying collection).