Recarga de webapplication en Tomcat

Tomcat es sin dudas uno de los motores de servlets mas usados para prototipar aplicaciones Java web generadas con Genexus.
Incluso en la versión Rocha GeneXus busca si está tomact instalado en la maquina de desarrollo y en caso de ser así realiza todas las configuraciones para que se cree en forma automática una webapplication con el nombre de la KB y se copie en forma automática todos los archivos para realizar la ejecución.
Muchas veces doy con personas que me cuentan que luego de estar un rato desarrollando en ese ciclo de implementación, ejecución, modificación y de nuevo ejecución notan que la memoria del tomcat se va a las nubes.
Este post intenta explicar porqué es que ocurre o puede ocurrir ese uso excesivo de memoria.

Una de las características que tiene tomcat es que usa una sola VM de Java para ejecutar todas las webapplication que existan dentro del mismo. Esto hace que cuando se baja, o se intenta recargar una webapplication no sea tan simple como bajar y subir una nueva VM, sino que se crea un nuevo classloader y se intenta liberar la memoria del classloader que antes era el encargado de ejecutar la webapplication. De esta forma si uno como programador no tiene cuidado puede dejar levantada toda la memoria del classloader si hay alguna de las clases que no puede ser liberada. Un caso muy común es programar usando singletons, en ese caso es seguro que cada vez que se baje o se reinicie la webapplication toda la memoria del classloader que maneja esa clase no va a ser liberada.
Como dije anteriormente este se ve acentuado sobre todo cuando se prototipa porque tomcat por defecto hace recarga de la webapplication cuando se mueve una nueva clase, entonces cada nueva clase que se mueve se suma toda la memoria del classloader que no pudo liberar.

Sobre todo para los usuarios GeneXus , que son los que mas leen este blog (eso espero ;)) es bueno saber que en las clases estándar del generador Java teníamos este problema porque hacíamos uso de algunos singletos. Ese comportamiento quedo solucionado a partir del U4 del generador Java de la versión 9.0 de GeneXus.

De todas formas puede pasar que la webapplication sigua sin liberar la memoria del classloader aunque se esta usando el U4 de Java. Generalmente las aplicaciones hacen uso de varias bibliotecas además de las clases estándar del generador… por ejemplo drivers JDBC o clases para el manejo de pdfs, etc. Si algunas de esta bibliotecas no libera sus clases entonces todo el classloader de esa webapp no se libera.
En ese caso la solución es copiar el jar o zip de esa biblioteca el directorio LIB general del tomcat en lugar del directorio LIB propio de la webapplication. Las clases que están en el LIB general del tomcat no se intenta “reciclar” cuando se reinicia una webapplication porque esas clases se cargan en otro classloader que es compartido por todas las webapplications.

Este último tip de copiar las bibliotecas que tienen este problema al LIB general del tomcat puede ser usado también en caso de estar usando las clases estándar de la versión anterior al U4 del generador Java. Eso si, en ese caso todas las webapplication GeneXus que están en el tomcat tienen que estar desarrolladas en la misma versión.

Gphone es en realidad Android

Hace tiempo que había rumores de que google estaba desarrollando un teléfono móvil, al cual se le llamaba GPhone.
Hoy nos enteramos que en realidad no era un aparato en lo que estaba google, sino que era una plataforma para teléfonos móviles a la cual llaman Android.
La plataforma es open source y tendría todo lo necesario para construir un teléfono celular. O sea no seria como dicen por ahí solo un sistema operativo para celulares basado en Linux que competiría con el Windows mobile.

Según dicen son mas de 34 compañías las que vienen trabajando en conjunto en este proyecto por más de 3 años, entre las cuales se encuentran Intel, Nividia, Motorola, LG, Samsung, Spring y T-Mobile.

Se esta anunciando el SDK para el 12 de Noviembre y los primeros apartitos basados en esa plataforma para la primera mitad del 2008.

No tengo dudas que esto será un éxito, considerando la pobreza general en términos de software que para mi tienen los teléfonos celulares hoy en día.
Y para todos los que alguna vez hemos intentado desarrollar aplicaciones para teléfonos móviles que tiene Java, seria un sueño vuelto realidad el tener una verdadera plataforma única en la cual algo que se desarrolla funcione de igual forma en todos los teléfonos que lo implementan.