Hazelcast – peculiaridad de near-cache

Un elemento muy interesante de Hazelcast son los listener, mediante los cuales, podemos programar un conjunto de acciones a realizar cuando se actúa sobre un mapa de datos distribuido. Para esto, el API de Hazelcast nos proporciona la interfaz EntryListener, que nos da la posibilidad de implementar los métodos que serán invocados por el API cuando se actúe sobre el mapa. Por ejemplo se notificará cada nueva entrada o borrado de un elemento.

El registro de un listener en un mapa se puede realizar de diferentes maneras (http://docs.hazelcast.org/docs/3.4/manual/html-single/hazelcast-documentation.html#entry-listener). Nosotros optaremos d por Spring:

Como vemos se trata de un mapa que registra un listener llamado SessionkeyInvalidationListener.

Mediante este listener, lo que pretendemos es realizar un conjunto de tareas relacionadas con la caducidad de una sesión que cada vez que elimine un elemento del mapa. Por lo que en la implementación damos cuerpo a los métodos entryRemoved y entryEvicted, que serán invocados por el API de Hazelcast cuando programáticamente se elimine una sesión del mapa (entryRemoved) o cuando se alcance el tiempo máximo de inactividad para una entrada, configurado en la declaración del mapa en el atributo max-idle-seconds (entryEvicted)

Utilizando esta combinación de elementos y el atributo max-idle-seconds hemos pretendido que sea el propio Hazelcast quien gestione la caducidad de sesiones de nuestra aplicación. Ya que consultando la documentación de Hazelcast para el atributo max-idle-seconds encontramos lo siguiente:

Es decir, si se consulta o actualiza una entrada en el mapa, se resetea el contador que decide su eliminación.

Por lo que en teoría, nuestra aplicación debería funcionar correctamente, lo que es falso, debido a un factor que me ha costado varias horas de depuración encontrar:

Debugueando me he dado cuenta que Hazelcast cacheaba localmente mis peticiones para recuperar las entradas del mapa, sin notificar al grid salvo la primera vez, de manera que en las sucesivas peticiones el grid no se enteraba de que había hecho una consulta y no reseteaba el idle time, por lo finalmente, una entrada que estaba siendo consultada constantemente, era desalojada del mapa por inactividad. La respuesta de tal comportamiento la tenemos en el near-cache. Configurando el mapa sin near-cache:

El funcionamiento ha sido el esperado.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: