Vergüenza de programador
Para el escale utilicé al principio Hibernate, pero me fue pesado aprender HQL, y los reportes que emitia se cortaban. Así que pasé a iBatis Mapper y me fue más fácil, flexible y rápido.. incluso usé iBatis DAO por su idependencia de implementación DAO.
Pero desde que lo puse, no recuerdo qué mes, el procesador se satura con el java... llegaba a ocupar casi el 100% del procesador... y mandaba error de Java Heap Memory (no indicaba la línea)
Continuamente reiniciaba el tomcat, modifiqué el pool de conexiones, aligeré código de consultas... y nada. Incluso puse en un cron para que se reinicié el tomcat cada 2 horas..... y nada.
Encontré en la web que el kernel de linux que usaba (2.4) provocaba ese error con java.. así que cambié a CentOS 4.4
Y nada.
Prácticament al día tenía que reiniciarlo manualmente 6 veces.
Supuse que el diseño de la página estaba mal, xq hacia llamadas recursivas para mostrar el menú de opciones.. así que con mi compañero nos pusimos a pasar todas las páginas a tiles. Cambié la biblioteca de ajax (usaba ajaxtaga y lo modifiqué para usar DWR), y cuando estaba haciendo las pruebas (demasiadas) con DWR.. volvió el mismo problema.
"Afortunadamente" tenía el log al detalle, y el error ocurría cuando hacía una consulta... y antes de hacer una consulta le pedía la conexión al iBatis DAO... y cada vez que hacía esta llamada, volvía abrir el archivo dao.xm y procesaba el stream para obtener el daoManager... siempre.
Así que cambié esa línea: colocar el daoManager como static y que se cargué sus valores en el static{} de la clase. Es decir, solo una vez.
Ya van más de 24 horas contínuas y no ha vuelto a dispararse el procesador.
Así que creo que tendrá para muchas horas más... y días.
Solo fue una línea mal programada que dió un dolor de cabeza por varias semanas.
Pero desde que lo puse, no recuerdo qué mes, el procesador se satura con el java... llegaba a ocupar casi el 100% del procesador... y mandaba error de Java Heap Memory (no indicaba la línea)
Continuamente reiniciaba el tomcat, modifiqué el pool de conexiones, aligeré código de consultas... y nada. Incluso puse en un cron para que se reinicié el tomcat cada 2 horas..... y nada.
Encontré en la web que el kernel de linux que usaba (2.4) provocaba ese error con java.. así que cambié a CentOS 4.4
Y nada.
Prácticament al día tenía que reiniciarlo manualmente 6 veces.
Supuse que el diseño de la página estaba mal, xq hacia llamadas recursivas para mostrar el menú de opciones.. así que con mi compañero nos pusimos a pasar todas las páginas a tiles. Cambié la biblioteca de ajax (usaba ajaxtaga y lo modifiqué para usar DWR), y cuando estaba haciendo las pruebas (demasiadas) con DWR.. volvió el mismo problema.
"Afortunadamente" tenía el log al detalle, y el error ocurría cuando hacía una consulta... y antes de hacer una consulta le pedía la conexión al iBatis DAO... y cada vez que hacía esta llamada, volvía abrir el archivo dao.xm y procesaba el stream para obtener el daoManager... siempre.
Así que cambié esa línea: colocar el daoManager como static y que se cargué sus valores en el static{} de la clase. Es decir, solo una vez.
Ya van más de 24 horas contínuas y no ha vuelto a dispararse el procesador.
Así que creo que tendrá para muchas horas más... y días.
Solo fue una línea mal programada que dió un dolor de cabeza por varias semanas.
Heavy: Lo que decis es muy cierto. Generalmente una deriva en tratar de dar soluciones por todas partes y uno no se da cuenta que la solucion está ante nuestras narices. Muchas veces pasa porque somo seremos humanos y nada más. Tu error es muy común así que hay que desdramatizar. Sos valiente en confesarlo por ello mi reconocimiento y razón por la que hago el comentario.
ResponderBorrarHey Heavy, gracias por tu comentario.
BorrarA pesar que este post lo escribí hace (puf) años (realmente) es bueno saber que a otras personas también les pueda interesar.
Saludos y gracias nuevamente por tu comentario.