MaxPermSize reserva memoria permanente

El lunes os hablaba de un intercambio de mails curioso gracias a la inmediatez e importancia de Twitter, anécdota que venía precedida por la mediocre impresión que me causó la live demo de JBoss Portal. Esto no podía quedar así, por ello, para quitarme el mal sabor de boca tecla, tal y como le prometí al amigo Tomás, hoy he sacado un ratín para hacer mis primeros pinitos con JBoss Portal. Las de hoy no han sido pruebas exhaustivas, pero la impresión a decir verdad sigue siendo mala no muy buena. Ahora explico por qué...

El primer paso ha sido bajarme un bundle o paquete que ya contiene una instancia preconfigurada de JBoss Portal 2.7.0 GA "desplegada" (I mean deployed...) bajo un servidor de aplicaciones JBoss 4.2.3, otro producto cañerito del fructífero matrimonio JBoss-RedHat. Como ya he aprendido la lección, ahora soy de los que empiezan por leerse el típico quickstart o manual de referencia con las acciones básicas para saber por dónde agarrar el embolao. Por lo que dice en el documentillo, tan sencillo como descomprimir el archivo descargado, acceder a la carpeta "bin" y ejecutar el típico run.bat si estamos en Windows (es el caso) o run.sh si estamos enel lado oscuro ;-), es decir, lo de siempre. Ésta es una de las cosas buenas que tienen los proyectos opensource, más concretamente, los proyectos relacionados con Java: la forma de arrancar un servidor de aplicaciones, el proceso de deploy de las aplicaciones, e incluso la estructura de directorios y el nombre de los archivos, es muy parecido casi siempre, con lo que en poco tiempo te quedas con la idea general. Lo dicho, que la idea está asumidisima hace tiempo, en cambio...

Como se aprecia en la imagen, en el log del servidor de aplicaciones JBoss, la flecha roja indica que JBoss AS ha arrancado sin problemas. Normalmente, ver un mensaje de este tipo en la consola suele indicar que el servidor está listo para que le den cañita brava. Precisamente eso es lo que he hecho, ya que siguiendo el manual, he accedido directamente a la URL inicial de JBoss Portal, http://localhost:8080/portal, con toda la ilusión del mundo por ver mi tesoro, digo, mi portal, en acción. Para mi desesperación, tanto Firefox como Explorer no son capaces de mostrarme nada, con lo que vuelvo a la consola para comprobar que los errores de tipo OutOfMemory campan a sus anchas por JBoss AS. En serio, no acabo de entender eso de que te bajes una demo preconfigurada de Internet, sigas las instrucciones de pé a pá, la arranques como Dios manda, y no veas nada, sólo las típicas y feas excepciones lanzadas por Java; I can't believe my eyes...

Menos mal que el texto OutOfMemory lo dice todo, con lo que en seguida he ido a inspeccionar el contenido del fichero run.bat, que es donde se le indica a JBoss qué JDK utilizar, qué variables de entorno configurar, y lo más importante, con cuánta memoria arrancar y el  máximo a reservar. Claro, en seguida veo la línea que puede estar dando guerra:

Traduciendo esto a lenguaje pseudo-natural: JBoss AS inicia (-Xms) el heap o cantidad de memoria reservada para la Java Virtual Machine a 128 Mbytes de RAM, permitiendo que este tamaño de pila o heap crezca hasta un tamaño máximo (-Xmx) de 512 Mbytes. ¡Pues parece que el niño no tiene suficiente!

Siguiendo los sabios consejos del compi situado a mi izquierda, el primer intento es equiparar el mínimo de memoria necesaria con el máximo permitido, es decir, poner los dos parámetros a 512. Reinicio de JBoss AS...,¡qué va, tampoco carbura! Entra entonces en liza desde el lejano Oeste, un nuevo consejo que acepto de muy buen grado: mantener equiparados los parámetros inicial y máximo, y probar fortuna con el parámetro MaxPermSize, un parámetro que sin saber a ciencia cierta a qué hace referencia exactamente, sabemos que ha dado buen resultado en otras ocasiones digamos que problemáticas ;-). Por tanto, la línea relativa a asignación de memoria de JBoss AS del fichero run.bat queda de la siguiente manera:

set JAVA_OPTS=%JAVA_OPTS% -Xms512m -XX:MaxPermSize=256m -Xmx512m

Se arranca de nuevo correctamente JBoss AS, accedo a la URL inicial..., ¡y por fin veo la luz! 

Qué bonito, ¿eh? Por fin tengo JBoss Portal up and running para exprimirlo y evaluarlo hasta límites insospechados, en otras palabras, listo para hacerle mil y una putadas ;-). 

Le debo una a mi compi, y otra a MaxPermSize, que según lo que explican claramente en esta página, indica el tamaño máximo de la memoria non-heap (también conocida como PermGen), en definitiva, el tamaño máximo de "memoria permanente" asignada a la JVM. 

Esperad, que ahora que tengo a JBoss Portal vivito y coleando, llega la prueba de las pruebas, una pequeña maldad que sólo se le ocurre a usuarios cabrones y enrrevesados como yo: Paro JBoss AS, mato el  proceso java.exe que anda dando vueltas por ahí, vuelvo a editar el fichero run.bat para dejarlo tal y como venía "de fábrica"(set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m), arranco de nuevo JBoss AS con esta nueva configuración y..., ¿qué creeís que ha pasado? Lo que me temía, aunque no me explico por qué, JBoss Portal ahora funciona de perlas, cuando la primera puesta en marcha tras la descarga inicial ha sido un auténtico desastre.

¿Explicación? Lo único que se me ocurre es la NO volatilidad del parámetro MaxPermSize, es decir, visto lo visto, entiendo que MaxPermSize modifica la memoria permanente asignada a la JVM, y JVM guarda (en este caso) esta configuración entre distintas sesiones o arranques, dándole igual que el parámetro desaparezca del run.bat y que se termine el proceso java.exe por las bravas. En otras palabras, un parámetro muy a tener en cuenta a la hora de lidiar con problemas de memoria muy típicos de las aplicaciones Java.

¿Conclusión? Aparte de la lección del parámetro MaxPermSize, y aunque al amigo Tomás no le haga gracia, he de decir que JBoss Portal se está cubriendo de gloria conmigo; no es normal que te bajes una demo configurada y que eso no funcione ni a tiros. Es más, diría que JBoss Portal está a puntito de ingresar en la "lista negra de Lonifasiko", de la que, aviso para aplicaciones navegantes, es realmente difícil salir ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Entregar o no el código fuente

Hoy domingo, voy a intentar, por una vez en la vida del blog, escribir un "post-pregunta" corto y un tanto controvertido. Me interesa más que nunca conocer la reacción y pensamiento de los frequent readers del blog, con lo que espero que el tema se debata en profundidad en los comentarios.

Allá voy: ¿Hay que entregar el código fuente de una aplicación software al cliente? Aunque parezca algo trivial, os juro que el asunto de la entrega del código fuente siempre es algo peliagudo. No me refiero a distribuir las librerías opensource o cierta funcionalidad de un software propietario que se ha utilizado en el desarrollo de la aplicación, ya que ahí entramos en el complicado terreno de los miles tipos de licencias específicas que existen a día de hoy. Librerías aparte, me refiero a la entrega del código fuente de la aplicación en su conjunto, al "conocimiento adicional y específico" generado para el cliente, en pocas palabras, la base, el "corazón" de la aplicación.

Digo controvertido, porque muchas veces directamente este punto o término ni siquiera se especifica en el contrato formal con el cliente; un vacío "legal" muy peligroso, ya que la empresa desarrolladora dirá que no tiene por qué darlo, mientras que el cliente, al ser el pagador, dirá que tiene derecho a él.

Pienso por tanto que la entrega o no entrega del código fuente es un punto que se ha de especificar claramente en el contrato que se firma con el cliente; conviene hacerlo porque luego siempre hay confusiones, malentendidos y malos rollos entre las partes implicadas, y tampoco es plan..., por lo que es mejor dejar todo "atadito" incluso antes de empezar a tirar las primeras líneas de código. En caso de acordar la cesión del mismo, opino también que dicha entrega de conocimiento debe de alguna manera facturarse; y si no se especifica nada, sorry but there is no source code, así de simple.

La pregunta que os dejo hoy es bien clara y obvia: ¿Qué opináis al respecto? ¿Qué soléis hacer en vuestros proyectos, en vuestra organización? La piedra está lanzada...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Panic Mode siempre a mano

Por desgracia panic mode no es un término que haya tenido yo el honor de acuñar; sin embargo, poco a poco me voy dando cuenta de que forma parte ya de mi vocabulario informático, de mi diccionario tecnológico elemental (...querido Watson). En mi caso, utilizo panic mode para definir aquella situación altamente embarazosa y de alto riesgo que se produce cuando hay que hacer una demo importante de una aplicación software (se podría aplicar a otros campos) e inexplicablemente el software que hasta hace cinco minutos funcionaba, misteriosamente deja de funcionar. ¿Os suena verdad? En el mundillo de los programadores, este escenario también se conoce como "efecto demo". Seguramente tod@s hemos vivido alguna vez esta situación que deja tus conocimientos de informática o de lo que sean a la altura del barro.

Te puede ocurrir en una demo ante tu jefe en la que te juegas el aumento de sueldo; imprevisiblemente puede aparecer cuando estás a punto de cerrar un contrato con ese cliente tan importante al que ya has engatusado con una buena mesa y buen vino; o peor aún, hace acto de presencia cuando estás a punto de "ilustrar" a tus propios compañer@s, con los que, con toda la razón del mundo, quedarás como el culo ;-).

La mayoría de las veces la catástrofe viene provocada por una tontería, un fallito mínimo que con calma descubriríamos en pocos minutos, pero lo cierto es que nos ha tumbado todo el sistema, y la situación y sobre todo, tu cara, lo dice todo. Es una situación agónica en la que por lo general la mente del programador se queda en blanco y no es capaz de pensar en ningún tipo de solución de forma rápida. Sólo quiere que termine el mal rato e irse para su casa...donde cenando o dándose un baño revitalizante se le iluminará la bombilla y se dará cuenta de por qué ha fallado su maldito software. Los juramentos en arameo que vienen a continuación forman parte del clásico pack del programador cabreado ;-).
A grandes males, grandes remedios, por lo que paso a explicar lo que hago yo para minimizar o solventar en la medida de lo posible estas situaciones nada agradables que sufriremos durante nuestra larga vida como desarrolladores. Significar que más que una solución, os voy a explicar lo que últimamente acostumbro a hacer para intentar remediar el temido efecto demo.

Se trata simplemente de tener preparada siempre una puerta trasera, una escapatoria como las del circuito de Mónaco. Todo esto viene gracias a que soy bastante fanático (queda mejor metódico) con los ficheros de configuración de las aplicaciones de software, de hecho, siempre intento que gran parte de la aplicación sea configurable por parte de los usuarios y que puedan cambiar ciertos parámetros de la aplicación sin tener que recompilar de nuevo todo. Es muy útil y versátil eso de que un usuario pueda poner los iconos e imágenes que más le gustan, pueda configurar el path donde se genera ese fichero temporal, o cuando se actualiza una URL a la que el programa llama, sólo tenga que cambiar ese parámetro, guardar el fichero y listo. Se dice que las aplicaciones que permiten esto soportan "cambios en caliente", es decir, que no hay que recompilar la aplicación para que coja los nuevos valores. El formato o base estándar de estos ficheros de configuración es en la mayoría de los casos XML, aunque hay variantes como los .properties de Java o los .config de Microsoft .NET.

A lo que voy es que en todas mis últimas aplicaciones he incluido en el fichero de configuración un parámetro denominado "PanicMode", just in case. Su funcionamiento es bien sencillo: si su valor es "0", el modo de funcionamiento de la aplicación es el normal, el esperado; en cambio, si editamos el fichero y ponemos el flag a "1", quiere decir que ha ocurrido una catástrofe, que activamos el plan de emergencia ya que estamos en pleno panic mode. Claro, no es sólo cambiar este valor y listo. ¿Qué implica poner este parámetro a 1? Que en el programa hemos preparado con anterioridad un camino seguro de ejecución por el que sabemos que no va a (debería) haber errores.

Imaginemos por un momento que en plena demo crucial para el futuro de la empresa nos tenemos que conectar a un web service externo securizado que nos devuelve una clave. ¿Qué ocurre si por lo que sea en ese momento se cae el web service o se cae nuestra LAN? Adiós demo y adiós cliente. Con lo fácil que es ser un poco precavido y emplear un poco de tiempo en guardar esa clave en el propio fichero de configuración (por ejemplo le llamaremos "PanicKey"), o en otro fichero temporal que tenemos preparado y escondido dentro de la maraña de carpetas del proyecto. Nadie se va a enterar, y aunque la demo puede que no quede tan espectacular ni dé tanta sensación de inmediatez, la aplicación funciona y te salva la papeleta...y la pataleta del cliente. Simplemente implica haber programado en la aplicación una sentencia condicional del tipo if (panicMode ==1). En este caso, la ejecución del programa estaría prevista, es decir, tendría un recorrido marcado por el que se saltaría la llamada al web service y cogería el valor directamente desde el fichero.

Os aseguro que esta clase de previsiones no es ninguna tontería y que te pueden sacar de muchos apuros. Además, no es muy costoso y haces que la aplicación sea muy configurable, cosa que muchos clientes y usuarios agradecen enormemente.

Aquí se despide un fan incondicional de la doctrina panic mode, una doctrina que todos los desarrolladores deberían admirar, venerar y por supuesto...¡implementar!

Así que ya sabéis, más vale panic modear que lamentar y llevarse malos ratos como esta señorita ;-)

SaludoX.

No olvides suscribirte al feed RSS para enterarte de todas las actualizaciones del Txoko de Lonifasiko .