15 julio 2013

Administración de memoria en Java

Hacia tiempo quería preparar un seminario sobre la "Administración de memoria en Java", por suerte hace un tiempo tuve el tiempo suficiente y pudimos realizar un lindo seminario sobre el tema.

Aprovecho para compartir la presentación que estuve preparando, la verdad tiene bastante trabajo encima e información muy detallada sobre cada área, espero que la encuentren de utilidad y que les genere ganas de investigar mas en profundidad todo el mundo de memoria en Java.



Saludos

Leer más...

06 marzo 2011

Marshalling and Unmarshalling

Hola primero que nada vamos a explicar que significan estas dos palabras y una breve introduccion de porque surgio el post.
Marshalling: Significa crear un documento XML de un árbol de contenido(En nuestro caso el arbol del contenido seria un Objeto Java).
Unmarshalling: Significa crear un árbol de contenido de un documento XML.
Basicamente esto seria serialization y deserialization.
Este post surgió porque hace un tiempo tuve que hacer un desarrollo donde venia la información en un XML y yo debía parsear el XML aplicar cierta lógica de negocio y devolver un XML como respuesta. Para esto lo único que me brindaron fueron un XML llamado request y otro response.


La verdad es que no tenia muchas ganas de hacer las cosas a mano así que me puse a investigar y encontré algunas cosas bastante interesante, como por ejemplo la API JAXB que es la tecnología de java que provee un API y una herramienta para ligar el esquema XML a una representación en código java.
Básicamente esta API nos provee un conjunto de Annotations y clases para hacer el bindeo entre nuestra estructura en los objetos Java y el XML, o mejor aun si nosotros poseemos el XSD del XML podes utilizar la herramienta xjc (Viene por defecto en la distrubución del jdk) para que nos genere la clases del dominio.

XMLs:


request.xml

<?xml version='1.0' encoding='utf-8' ?>
<Parameters>
  <UserId>AH875</UserId>
  <SystemId>Test</SystemId>
</Parameters> 

response.xml

<?xml version='1.0' encoding='utf-8' ?>
<Response>
  <Status>Ok</Status>
  <Data>
   <SubSystem>
    <SubSystemId>1</SubSystemId>
    <Name>SubSystem1</Name>
   </SubSystem>
   <SubSystem>
    <SubSystemId>2</SubSystemId>
    <Name>SubSystem2</Name>
   </SubSystem>
  </Data>
</Response>

Como les dije antes la verdad no tenia muchas ganas de hacerlo a mano así que empece a buscar una herramienta que genere el XSD en base al XML y encontré una muy buena, les dejo el link
Trang(trang20030619.zip).

Si la bajan y la utilizan lograran obtener los XSD de sus XML aquí les dejo los míos

XSDs:

request.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="Parameters">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="UserId"/>
        <xs:element ref="SystemId"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="UserId" type="xs:NCName"/>
  <xs:element name="SystemId" type="xs:NCName"/>
</xs:schema>

response.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="Response">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Status"/>
        <xs:element ref="Data"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Status" type="xs:NCName"/>
  <xs:element name="Data">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="SubSystem"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="SubSystem">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="SubSystemId"/>
        <xs:element ref="Name"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="SubSystemId" type="xs:integer"/>
  <xs:element name="Name" type="xs:NCName"/>
</xs:schema>


Ahora que tenemos nuestros xsd podemos utilizar xjc para obtener nuestras clases java con sus respectivas annotations.

Les dejo el ejemplo completo para que puedan descargarlo y probarlo. La verdad hay muchas cosas ya resueltas de manera elegante y eficiente solo hace falta conocerlas.

Example.

Saludos,
Luis

Leer más...

02 enero 2011

Jasper Reports -Virtualizar-

Hoy les contare sobre un problema que tuve durante estos días, estoy en el desarrollo de una aplicación constituida con Java para el lado servidor y Flex para el lado cliente, últimamente la aplicación había tenido unos problemas con el consumo de memoria luego de analizarla descubrí que esto era básicamente por dos motivos uno de ellos relacionados con Hibernate y el levantamiento de 60000 objetos en memoria lo cual al fin de cuentas lo termine resolviendo con NameQuery, pero aun tenía problemas cuando se ejecutaban varios reportes ya que la memoria del servidor subía inmesuradamente, a continuación les dejo la solución que encontré.


Antes que nada quiero recomendarles que cuando tengan un problema de memoria utilicen jVisualVM es un programa que te deja conectarte al servidor y ver la cantidad de instancias en memoria y así analizar cuál es la que se queda alocada o cuales consumen mucho, como primer paso use el programa y me conecte al servidor (Tomcat) y comencé a arrojar reportes al parecer el GC (Garbage Collector) corría de forma normal pero cuando había muchos reportes al mismo tiempo veía que la cantidad de instancia de JRTemplatePrintText crecía drásticamente.
Luego de investigar un poco encontré que Jasper Report durante su proceso de fill (Obtener los datos y rellenar la plantilla del informe con estos) levantaba los objetos en memoria, entonces la forma de abordar este problema es de dos maneras:
La paginación y la virtualización.
Paginación se refiere a obtener el informe en trozos, en lugar de recoger toda la información de golpe, pero como al final los datos se tienen que mostrar juntos en un único informe, nos introducen la virtualización. La virtualización es una técnica que consiste en serializar los datos, para no saturar la memoria heap.
Cabe aclarar que incluir virtualización conlleva la pérdida de rendimiento.

Aquí un ejemplo de cómo tendríamos que usar la virtualizacion:


JasperPrint jasperprint = null;
JRFileVirtualizer virtualizer = new JRFileVirtualizer(10, "tmp");

long start = System.currentTimeMillis();  

filterParameters.put(JRParameter.REPORT_VIRTUALIZER, virtualizer);

jasperprint = JasperFillManager.fillReport(this.reportFile,this.filterParameters, this.databaseConnection);

virtualizer.setReadOnly(true);
logger.info("Filling time : " + (System.currentTimeMillis() - start));

// Usamos los exportadores para generar el reporte en lo que nosotros queramos.

virtualizer.cleanup();

Se vemos el ejemplo veremos que básicamente creamos un JasperPrint como lo haríamos normalmente pero al momento de generar este JasperPrint por medio del método fillReport de la clase JasperFillManager notamos que en los parámetros le pasamos un Virtualizer esto básicamente quiere decir que Jasper ira creando archivos temporales en la carpeta que le pasamos como segundo parámetro y el primer parámetro es usado para saber el tamaño máximo de los archivos, como ultima línea no debemos olvidar hacer un cleanup del virtualizer para borrar los archivos creados.

Bueno espero que este simple post les sirva como me sirvió a mí encontrar esta técnica para no malgastar memoria durante la generación de reportes ya sean medianos o grandes
Vale recordarles que deben tener en cuenta el balance entre performance y gasto de memoria esto lo pueden manejar con el tamaño máximo de los archivos.

Saludos,
Luis

Leer más...

28 agosto 2010

Semaphores

Hola como están, hoy estaremos viendo un ejemplo de cómo usar Semaphores en Java, a partir de la versión de 1.5 se hicieron unas extensiones importantes al paquete java.util.concurrent la cual vino acompañada de la clase Semaphore la cual brinda la funcionalidad que necesitaremos.

Para entender su uso lo haremos en base a un ejemplo real, en mi trabajo hace unos días surgió el siguiente issue, tenemos algunas clases singleton que funcionan como Providers, el problema es que a su vez tenemos procesos concurrentes que usan este Provider y cada uno hace un refresh de los datos para tener la ultima versión de los datos. Durante esta semana sucedió que N procesos (Fijaremos N=5) corrieron casi al mismo tiempo por ende cada uno de ellos intento refrescar el singleton todos a la vez como el método que hace el refresh esta sincronizado sucedía que actualizaba los datos para 1 Thread y los otros 4 Thread esperaban, después volvía a refrescar para el siguiente Thread y los restantes esperaban y así sucesivamente, les adjunto una imagen para entender mejor el problema.
Problem Image
Para evitar que los 5 Thread realicen el refresh se decidió ejecutar solo un refresh y encolar los otros 4 esperando que el que está realizando el refresh termine, para esto tuvimos que modificar nuestro singleton y utilizar Semaphores y syncronized por medio de un mutex. Aqui está la clase singleton modificada y ahora explicaremos cada paso.

 
package com.javacuriosities.examples;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.Semaphore;

public class Singleton {

 private static Singleton instance;

 private volatile boolean refreshing = false;

 private Object mutex = new Object();

 private List<Semaphore> pendings = new ArrayList<Semaphore>();

 public synchronized static Singleton getSingleInstance() {
  if (instance == null) {
   instance = new Singleton();
  }
  return instance;
 }

 public void refreshAll(String threadName) {
  if (!checkRefreshingStatus()) {
   refresh(threadName);
  } else {
   Semaphore markPending = addSemaphore(threadName);
   acquireSemaphore(markPending, threadName);
  }
 }

 private void refresh(String threadName) {
  try {
   refreshInfo(threadName);
  } catch (Exception e) {
   e.printStackTrace();
  } finally {
   releasePending();
  }
 }

 private void acquireSemaphore(Semaphore markPending, String threadName) {
  try {
   if (markPending != null) {
    System.out.println("Acquire semaphore: " + threadName);
    markPending.acquire();
   } else {
    System.out.println("Avoid semaphore: " + threadName);
   }
  } catch (InterruptedException e) {
   e.printStackTrace();
  }
 }

 private Semaphore addSemaphore(String threadName) {
  Semaphore markPending = null;
  synchronized (mutex) {
   if (isRefreshing()) {
    markPending = new Semaphore(0, true);
    pendings.add(markPending);
    System.out.println("Add semaphore to: " + threadName);
   }
  }
  return markPending;
 }

 private void releasePending() {
  synchronized (mutex) {
   System.out.println("Release semaphores");
   for (Semaphore semaphore : pendings) {
    semaphore.release();
   }
   pendings.clear();
   refreshing = false;
  }
 }

 private synchronized boolean checkRefreshingStatus() {
  boolean previousState = refreshing;
  if (!refreshing) {
   refreshing = true;
  }
  return previousState;
 }

 private void refreshInfo(String threadName) {
  for (int i = 0; i < 1000; i++) {
   System.out.println("Executing refresh: " + threadName);
  }
 }

 public boolean isRefreshing() {
  return refreshing;
 }
}
Iré explicando todos los cambios que hemos efectuado para conseguir lo que esperábamos a su vez iremos viendo como seria el flujo de ejecución. Nota: La clase ha sido modifica para que sirva para las pruebas y el ejemplo.
1) El método refreshAll dejo de ser synchronized.
2) Apenas comienza este método tenemos un IF el cual llama a un método synchronized donde se pregunta si se está refrescando y se cambia el estado del flag refreshing.
3) El primer Thread que llegue a esta parte entrara por el IF los demás se irán por el ELSE.
4) El Thread 1 comienza a refrescar la información, los otros van por el lado del ELSE y entran en el método addSemaphore como vemos este método usa sincronización por mutex esto es para asegurarnos que no se agregan semaphores a la lista mientras la estamos liberando por otro lado, si la lista no se esta liberando y además aun está corriendo el refresh creamos un semaphore y lo retornamos.
5) Si se pudo crear el semaphore se intentan hacer acquire del mismo, si no se logro crear significa que el refresh termino y no era necesaria la espera. Usamos el método acquire para decirle a un semaphore que se quede esperando hasta que sea liberado esto sería el equivalente a hacer this.wait() y esperar que por otra parte del código se haga un this.notify().
6) Otro tema importante es que si la lógica del refresh falla igual debemos liberar los semaphores pendientes sino estaremos lockeando el proceso., por eso el releasePending se encuentra en un bloque finally.

Notar que los semaphore son creados con 0 permits lo que signica que al hacer acquire quedaran esperando que la cantidad de permits este en 1, esto se logra por medio del método release que incrementa en 1 los permits del semaphore.

Les adjunto un zip con la clase singleton mas una clase de test que dispara 20 Threads. Espero que este post les sea de ayuda para ver algún ejemplo de concurrencia y threading en Java, cualquier cosa que no se entienda del post todas las preguntas son bienvenidas al igual que las criticas.

Este post es en honor a tuky que últimamente está muy curioso sobre temas varios de programación.

Example

Saludos,
Luis

Leer más...

09 mayo 2010

OSGi (First Steps)

Decidí hacer este post porque no encontré ningun tutorial que nos explique OSGi desde cero, aclaro que en este post haremos una introducción para que después podamos continuar con algo más avanzado.

¿Que es OSGi?
OSGI (Open Services Gateway Initiative), podríamos definirlo como un sistema (o framework) modular para Java que establece las formas de crear módulos y la manera en que estos interactuaran entre sí en tiempo de ejecución. OSGi intenta solventar los problemas del tradicional "classloader" de la máquina virtual y de los servidores de aplicaciones Java. En OSGI, cada módulo tiene su propio classpath separado del resto de classpath de los demás módulos.

Este framework proporciona a los desarrolladores un entorno orientado a servicios y basado en componentes, ofreciendo estándares para manejar los ciclos de vida del software.
OSGi esta divido en capas que en proximo post iremos cubriendo por ahora se mencionan para que se conozca la existencia de ellas.

Security Layer.
Module Layer.
Life Cycle Layer.
Service Layer.
Execution Environment.

OSGi Alliance
La OSGi Alliance es un consorcio de empresas tecnológicas a nivel mundial que trata de asegurar la interoperabilidad de las aplicaciones y servicios basados en esta plataforma entre las empresas que componen este consorcio, podemos encontrar compañías de diversa índole: automoción, aeronáutica, fabricantes de electrodomésticos, telecomunicaciones, fabricantes de teléfonos... Algunos ejemplos de miembros: Motorola, Nokia, Mitsubishi Electric Corporation, Vodafone Group Services, LinkedIn, LG Electronics...
La alianza proporciona las especificaciones, las implementaciones de referencia, las suites de prueba y la certificación.

Especificacion OSGi
OSGI proporciona un marco de trabajo java de uso general, seguro y administrado que
soporta el despliegue dinámico de aplicaciones conocidas como "Bundles" o módulos.
Algunas de las características que componen este marco de trabajo:

  • Es un sistema de módulos para la plataforma java.
  • Incluye reglas de visibilidad, gestión de dependencias y versionado de los bundles.
  • Es dinámico.
  • La instalación, arranque, parada, actualización y desinstalación de bundles se realiza dinámicamente en tiempo de ejecución sin tener que detener por completo la
    plataforma.
  • Se trata de una arquitectura orientada a servicios.
  • Los servicios pueden ser registrados y consumidos dentro de la VM.
Implementacones OSGi
Lo bueno de tener una aplicación modular es que a diferencia de una aplicación web nosotros vamos deployando unidades independientes las cuales se pueden cambiar con gran facilidad, esto quiere decir que si necesitáramos reemplazar un modulo por otro muchas veces no sería necesario detener toda la aplicación sino ciertos módulos y todo seguiría andando, además tenemos versionado de Bundles (Módulos) lo cual es muy útil para poder ir haciendo que nuestros módulos usen otros pero de alguna versión especifica.
Podemos encontrar varias plataformas certificadas en OSGi las cuales cumplen con la especificación de modo que si nosotros desarrolláramos nuestros módulos ellos podrían correr en cualquiera de estas implementaciones, algunas de ellas son:
  • Apache Felix.
  • Eclipse Equinox.
  • Knopflerfish.
  • Newton Project.
Preparando mi entorno OSGi
Para este post utilizaremos la implementación de Eclipse Equinox para nuestros ejemplos, nos dirigimos a Eclipse Equinox desde aquí podremos realizar la descarga del entorno de trabajo, tenemos varias opciones:

Descarga de la implementación OSGI base: Se trata de un fichero .jar (bundle),
que contiene los elementos básicos para poder ejecutar nuestro entorno.

Descarga completa de equinox: Se trata de un fichero .zip que contiene el bundle
base comentado anteriormente, más todas las configuraciones e implementaciones
de los servicios OSGI.

Descarga de los bundles opcionales: Mediante esta opción podremos descargar
uno a uno los bundles de equinox que implementan los diferentes servicios de
OSGI.

Para este ejemplo bajaremos la descarga completa para facilitar las cosas, luego podremos descomprimir este zip en nuestro disco. Dentro de la carpeta plugins del zip que descargamos encontraremos un jar llamado org.eclipse.osgi_3.x.x_xxx.jar el cual es util para dos cosas la primera levanta el entorno OSGi y desde aqui podremos instalar, iniciar, detener, desinstalar nuestros módulos, y además podremos usar este jar para desarrollar en el eclipse ya que contiene las clases/interfaces de la implementación OSGi. Les dejo un print screen de mi eclipse con el desarrollo del ejemplo que sigue.

OSGiEclipse.png

Ejemplo Basico
Como es típico empezaremos con un Hello World, ósea aquí no estaríamos construyendo una aplicación que nos diga Hello World sino que estaríamos creando un modulo el cual por vivir en un contender OSGi tiene un ciclo de vida completo. Básicamente crear un modulo sería crear un jar con nuestras clases y un archivo MANIFEST.MF

Entendiendo el MANIFEST.MF
El Manifesft.mf no es más que un archivo de texto en el cual se agregan directivas del tipo clave: valor, las cuales juegan un papel muy importante ya que son las que irán diciéndole al marco de trabajo OSGi algunas de las cosas importante sobre nuestro modulo a continuación muestro un Manifest de ejemplo y explico sus directivas.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: HelloWorld
Bundle-SymbolicName: com.javacuriosities.osgi.helloworld
Bundle-Version: 1.0.0
Bundle-Activator: com.javacuriosities.osgi.helloworld.Activator
Import-Package: org.osgi.framework;specification-version="1.4.0"
Manifest-Version
Define la versión del archivo MANIFEST.MF.

Bundle-ManifestVersion
Indica la especificación de OSGi sobre la que está basada el bundle. Por defecto, si no se indica nada, el valor es 1. Este valor indica que el bundle se basa en las reglas de la especificación OSGI 3. Si tiene valor 2, se tratará de la especificación de OSGI 4.

Bundle-Name
Indica el nombre corto del Bundle debe ser human-readable.

Bundle-SymbolicName
Esta etiqueta define un nombre único para el bundle. Con este nombre es con el que trabajaremos en el entorno de ejecución.

Bundle-Version
Indica la versión de nuestro bundle, dentro de nuestro entorno podríamos tener diferentes versiones de un mismo bundle.

Bundle-Activator
Indica que clase funcionara como Activator, la cual es una clase que debe implementar la interfaz BundleActivator de modo que podamos entrar dentro del ciclo de vida de nuestro Bundle.

Import-Package
Por medio de esta directiva le decimos que paquetes queremos importar, si nos ponemos a pensar esta línea es muy importante porque nuestro jar solamente tendra nuestras clases pero por ejemplo la interfaz BundleActivator ya es parte del modulo core de OSGi asi no estaría dentro de nuestro jar así que por medio de esta directiva la importamos para que todo funcione.

Implementando nuestro Activator

package com.javacuriosities.osgi.helloworld;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator{
@Override
public void start(BundleContext arg0) throws Exception {
 System.out.println("Hello World"); 
}

@Override
public void stop(BundleContext arg0) throws Exception {
 System.out.println("Bye Bye"); 
}
}
Empaquetando e instalando
Luego de poder crear nuestro modulo deberemos empaquetarlo como un jar podríamos usar el eclipse o el comando jar que viene con java, el jar nos debería quedar de la siguiente forma

com.javacuriosities.osgi.helloworld_1.0.0.jar
    com\javacuriosities\osgi\helloworld\Activar.class
    META-INF\MANIFEST.MF
Debemos iniciar nuestro entorno OSGi para esto haremos lo siguiente iremos al directorio donde descomprimimos el entorno Eclipse Equinox y dentro de la carpeta plugins ejecutaremos la siguiente línea de comando, luego veremos que el prompt cambia a osgi> y ahí pondremos ss para ver nuestros bundles instalados.

java -jar org.eclipse.osgi_3.x.x_xxx.jar -console

Ahora instalaremos nuestro bundle(.jar) copiaremos nuestro bundle al Disco C:\ y ejecutaremos el comando

install file:c:\com.javacuriosities.osgi.helloworld_1.0.0.jar

si todo va bien aparecerá un mensaje del tipo Bundle id is XX, ahora con este id ya podremos iniciar, detener y desinstalar nuestro modulo. Para probar ejecutaremos estos dos comandos.

start XX --> Ahi veremos nuestro mensaje del método start de la clase Activator.
stop XX --> Ahi veremos nuestro mensaje del método stop de la clase Activator.

Adjunto un screen de la consola con los comandos.

OSGiConsole.png

Bueno esto ha sido por este post, espero haber sido lo suficientemente claro para que se entienda el ejemplo y los conceptos básicos de OSGi, cualquier pregunta o sugerencia es bien recibida.

Saludos y hasta pronto.

Leer más...