Кэширование пользовательской сессии в hazelcast

Вопросы и проблемы
1

Добрый день.

Версия Jmix 2.7.6
Хочу воспользоваться Hazelcast для надёжного хранения пользовательской сессии
в распределённом кластере.
Для примера взял Hazelcast Embedded с одной нодой.
Указал в настройках кэша провайдера Hazelcast:
spring.cache.jcache.provider = com.hazelcast.cache.HazelcastMemberCachingProvider
Как я понял в Jmix по умолчанию сохраняется 3 типа кэшей в Hazelcast:

  • jmix-eclipselink-query-cache
  • resource-roles-cache
  • row-level-roles-cache

Пользовательской сессии в них не нашёл, поэтому подключил предлагаемую Hazelcast конфигурацию для хранения пользовательских сессий:

  • В build.gradle добавил библиотеку ‘org.springframework.session:spring-session-hazelcast:3.5.5’
    (последняя версия которой не работала, не могло найти класс ThemeSource на этапе запуска приложения)
  • Добавил конфигурацию SessionConfig.java
  • Добавил ендпоинт /public/hi, чтобы убедиться, что id сеанса совпадает с ид сеанса в экземпляре Hazelcast

При таком подходе, если перейти по ендпоинту /public/hi, в экземпляре хазелкаст появляется карта с данными текущего сеанса пользвателя.

НО, при попытке перехода на главную страницу возникает ошибка:

java.lang.NullPointerException Cannot invoke “com.vaadin.flow.function.DeploymentConfiguration.isProductionMode()” because “config” is null

Вопрос
Что я не так делаю и есть ли у Jmix выработанный подход к хранению пользовательских сеансов в Hazelcast?

Репозиторий с воспроизведением ошибки: sirkrono/Hazelcast session cache

4

Здравствуйте!

Вынужден вас огорчить - репликация HTTP-сессий не работает в Jmix приложениях.

Основная причина - сессии в реальных приложениях слишком большие (5-20M), так что реплицировать их на каждый запрос нереалистично с точки зрения производительности.

В связи с этим мы не тестируем репликацию сессий и не рекомендуем на нее полагаться. Для работы кластера серверов требуется включить sticky sessions (AKA session affinity) на балансировщике нагрузки.

С уважением,
Константин

6

Спасибо за развёрнутый ответ.

Тогда следом такой вопрос: насколько проблематично будет отказаться от Hazelcast и использовать, скажем, Redis в кластере с Jmix? Какие плюсы в этом плане у Hazelcast, почему команда Jmix выбрала именно его как провайдера кэша по умолчанию? У нас больше компетенций с Redis, поэтому хотелось бы понимать что мы получим, перейдя на хазелкаст.

7

Для нас реализация кэшей на Hazelcast это референсная имплементация которую мы регулярно тестируем. Выбрали Hazelcast потому что он может работать как embedded библиотека, что в простых случаях избавляет от поднятия отдельного сервиса кэша.

Redis тоже должен работать, но мы с ним не тестируем.