J2EE

Problemas con PermGen

Uno de los problemas recurrentes de los servidores de aplicaciones, y que ni siquiera profesionales certificados en Java me han sabido resolver, es el error de memoria agotada en PermGen. El caso es que el servidor se rompe y hay que reiniciarlo, solución nada aconsejable en entornos de producción.

Pues bien, tras algunas búsquedas y lecturas varias, he hallado la solución al problema, y lo que es mejor, una explicación detallada de todo el proceso. Al parecer, el recolector de basura de Java es generacional. Existen cuatro generaciones o etapas: eden, young, old y permanent. De izquierda a derecha, la diferencia fundamental (que no la única) es que el recolector de basura pasa con menos frecuencia que en la anterior. Como ya sabía el lector avezado, por la generación permanente no pasa nunca, así que cuando se llena, salta la conocida excepción que muchos tememos.

El artículo explica detalladamente cómo evitarlo para volver a dormir tranquilos.

Actualización 10/06/2010. He encontrado un artículo que explica magistralmente, y con ejemplos, las causas y soluciones del problema a nivel de implementación.

Java

JavaMi entrada en el mundo Java ha sido nada gradual y de la mano de PYMESevill@, un interesante proyecto que ofrecerá una plataforma de contenidos y comercio electrónico a las PYME de la provincia de Sevilla.

Aunque sigo prefiriendo PHP para mis propios desarrollos, en estos meses he comprobado que J2EE es una especificación sólida y compleja que no sólo propicia, sino que fuerza a desarrollar siguiendo esquemas y patrones. Su integración con entornos como Eclipse ofrece herramientas muy útiles para tener un control total sobre el código. También he agradecido la comodísima gestión de los servicios web; una vez que se conoce el mecanismo, construirlos es baladí.

Claro que hay aspectos que no terminan de convencerme. Como soy un programador responsable, no soy partidario de tanta rigidez a la hora de usar objetos, lo que genera excesivo código innecesario. También echo de menos la facilidad de modificar un fragmento de código sin tener que reiniciar el servidor, por más que Tomcat autodetecte los cambios y dispare el despliegue de la aplicación. Por último, Java me parece menos eficiente que PHP, o al menos no tan susceptible de ser optimizado.

A medida que profundice en este complejo universo de desarrollo, es posible que mi opinión varíe. Pero sin duda, mi perspectiva será mucho más rica y argumentada.