Bueno, quería compartir mi experiencia tratando de configurar un caché distribuido.
En la empresa para la que trabjo estamos desarrollando un sistema que utiliza
Hibernate 3.2,
Spring 2.0 y Flex 2.0, que consta de una aplicación de acceso público, y otra de acceso interno, para administración. La de acceso público se encuentra clusterizada en 4 servidores mientras que la otra sólo en 1. Todo esto bajo RedHat, a 64 bits. En definitiva, cuenta con 5 nodos.
Para mejorar la performance del conjunto, se incorporó una caché de 2do nivel en Hibernate. La primera prueba se realizó utilizando
SwarmCache, que se encuentra en RC2 desde hace tiempo, y que utiliza, como otras,
JGroups (¿o es JavaGroups?)para manejar la comunicación entre nodos del cluster. Fué un total fracaso, principalmente porque luego de un tiempo los nodos dejaban de reconocerse entre sí, y los cambios incorporados en uno no llegaban a otro. No hubo posibilidad alguna de detectar qué estaba produciendo la falla, por lo que finalmente migramos a
EHCache, version 1.4.1. Todo perfecto en entorno de desarrollo, tanto local como clusterizado con otras pcs del equipo de desarrollo (que por cierto, utilizan Windows). Luego, el deploy en el entorno de testing, la catástrofe, la debacle total. EHCache (que utiliza discovery de nodos mediante multicast, y comunicación medinte
RMI) se negaba a reconocer a las aplicaciones instaladas en otros equipos. En realidad, se veían, se conectaban, pero al momento de transmitir actualizaciones a datos, una críptica NoRouteToHostException indicaba que no, que no se había actuaizado nada.
Para hacerla corta, y luego de mucho buscar en la web, se descubrió que el problema se da por la forma en que funciona RMI, y cómo lo utiliza EHCache. Si bien este último permite indicar en qué interfaz y puerto debe escuchar el "localizador" de RMI, no permite establecer estos parámetros para el segundo "server" que levanta RMI, aquel a donde otros clientes se conectan para interactuar, con lo cual toma un puerto aleatorio cada vez que se levanta. Esto, sumado a un firewall totalmente restrictivo configurado en cada uno de los nodos (es decir, no conformes con la existencia de firewalls que prevengan el acceso hasta los nodos, el administrador decidió colocar uno en cada uno de ellos, para limitar la comunicación entre pares), hizo que padeciésemos horas de sufrimiento.
Por suerte, la historia tiene final feliz, la cosa está funcionando correctamente ya. Para un detalle más preciso de este problema, recomiendo
esta página, donde se documenta y resuelve unn bug en otra aplicación con arquitectura semejante.
Moraleja, el clustering del caché de 2do nivel de hibernate no es moco de pavo. Hay muchas opciones, algunas más potentes que otras, otras más sencillas de implementar, etc, etc, etc. Hsta que la cosa no llegue a un entorno isomorfo con el de producción, no podremos asegurarnos que funcionará como esperamos. Nos quedron por probar
Terracotta,
OSCache y
JBossCache.
Respecto de SwarmCache, es posible que funcione correctamente, ya que descubrimos una regla de ruteo para tráfico multicast en uno de los servidores que podría haber estado causando la falla original (obviamente, la descubrimos luego de haber hecho todo el cambio a EHCache).
Espero que la experiencia sirva, hasta la próxima!