Spring Agile Tour Perú

 

En el blog de mi amigo Lenon Shimokawa veo que se estan haciendo actividades para la difusión de Spring y Metodologías Ágiles.

Seria bueno asistir para tener contacto con las nuevas tecnologias y tecnicas que vienen funcionando ya en todo el mundo.

Ya era hora que haya esta difusión sobre todo con gente capacitada y con experiencia en el tema ahi estaremos.

AIX - Cúantos procesadores tengo ?

 

Una forma directa de saber la cantidad de procesadores que tenemos en un AIX sin entrar a la consola de HMC es mediante el comando sar:

 

La cantidad de procesadores esta dada por la columna %entc segun vemos en la grafica tenemos 1.8 de procesador.

Generación y Propag. Automatica de Plugin

 

Una de las novedades del was 6 trajo en su momento fue la administracion de web servers la cual fue sin duda algo interesante ya que la consola se convirtio de una consola administrativa a una consola de servicios integrados yendo mas alla del application server.

Existe un pequeño detalle que podria causar problemas con la configuracion del web server desde la consola es la auto generacion y autopropagacion del plugin.

Para los que venimos de was51 la receta era sencilla:

Cuando instalas una nueva aplicacion regeneras el plugin y los propagas manualmente y punto.

Pero ahora bajo ciertas acciones como por ejemplo:

• Creación de un web server.
• Se instala una nueva aplicación.
• Se desinstala una aplicación.
• Un virtual host es creado o actualizado.

El plug se regenera y se propaga a los web servers recordemos que esta configuracion en un tiempo es recargada y tomada en cuenta para los enrutamientos.

Este comportamiento puede dar lugar a comportamientos esotericos que rayan la razon...

Podemos evitar esto deseleccionando las opciones por default:

• Automatically generate the plug-in configuration file
• Automatically propagate plugin configuration file

Hallando el sizing de la sesión en websphere

 

En el trabajo tuvimos un problema por la memoria consumida por una aplicacion tuvimos problemas de Out of Memory muchas veces en esos casos surgen las dudas:

• Demasiada informacion en la sesion.
• Demasiada memoria en estructuras de datos.
• Problema de fragmentación de jvm.

Yo me incline a pensar en problemas de demasiada informacion en la sesion pero como poder demostrar eso ?

Pues haciendo uso del poderoso PMI y sus metricas que ahora a partir de websphere 6.x se pueden ver desde la misma consola.

Buscamos en las metricas de tipo Runtime, Custom Monitoring Level (esto para no saturar el app server con metricas que no nos interesan).

 

Como vemos en la antepenultima fila bajo las estadisticas de Servlet Session Manager vemos la metrica SessionObjectSize que nos da un aproximado del peso promedio de la sesion.

 

Tenemos que darle click en el check y luego click en el boton Activate de la parte superior.

 

Luego de esto ya podemos ver la metrica variar a lo largo del tiempo en la opción: Monitoring and Tuning -> Current Activity -> Seleccionas el server donde activaste la metricas y das click en el boton Start Monitoring:

 

Tras la verdad: getLinkedException

En el trabajo se presento un problema en estos dias se trato de una conexión a un Conexión Factory definido en el was.

Se obtenia la excepcion de JMS 2005 la cual no nos daba mucha información al descompilar el codigo se vio que la excepcion era manejeada de la siguiente forma:

try
{

props = new Hashtable();
props.put("java.naming.provider.url", Messages.getString("PROVIDER_URL"));
props.put("java.naming.factory.initial", "com.ibm.websphere.naming.WsnInitialContextFactory");
context = new InitialContext(props);
..

}
catch(Exception e)
{
Log.fatal("[Servicio]Error al inicializar servicio:", e);
System.exit(-1);
}

Ese catch de exception hummmm.. no me gusta mucho.

Lo que necesitamos para poder solucionar el problema no es la excepcion generica de jms sino la excepcion propia del provider (mq en este caso) pero como la obtenemos ?

Pues simplemente cambiemos el bloque catch a la siguiente forma:

catch(JMSException e)
{
Log.fatal("[Servicio][run]Error JMSException: " + e.getLinkedException());
e.printStackTrace();
Log.fatal("[Servicio][run]Error" + e.getMessage());
}

Gracias al getLinkedException podemos ver las excepcion lanzada por el provider y ver el verdadero rostro de la excepción.