Я реализовал Spring Session с Redis в моем устаревшем приложении Spring MVC. Я также использовал DefaultCookieSerializer для установки jvmRoute, потому что мне нужно некоторое сходство с сервером для выполнения заданий Talend.
Когда я запускаю интерфейс и просматриваю страницу в Chrome, я вижу, что к сеансу добавлен jvmRoute. Если я изменю его с «node1» на «node2», сеанс сохранится. Если я повторно разверну сервер и сделаю запросы во время этого развертывания, я буду перенаправлен на другой узел в кластере, а это означает, что Spring Sessions работает идеально.
Однако я не могу получить привязку к серверу, потому что, когда я отлаживаю HttpServletRequest, поскольку он входит в мое приложение Spring, в HttpServletRequest.getSession().getId() нет jvmRoute (хотя шестнадцатеричное число соответствует тому, что я вижу в Chrome), и это то, что я передаю на задание Talend.
Если я вернусь к сеансу Tomcat и установлю jvmRoute в компоненте Engine server.xml, я увижу, что jvmRoute добавлен к идентификатору сеанса как в Chrome, так и при отладке кода.
Что именно делает DefaultCookieSerializer? Я думал, что он редактирует файл cookie по мере его создания, и именно так файл cookie должен храниться в Redis. Таким образом, любое использование этого файла cookie после его создания должно иметь прикрепленный jmvRoute, если вы настроили его таким образом.




What exactly does the DefaultCookieSerializer do? I thought it edits the cookie as it is being created, and that is how the cookie is to be stored in Redis. So any use of this cookie subsequent to being created should have the jmvRoute attached if you set it up that way.
Во-первых, важно понимать, что сам файл cookie не хранится в хранилище сеансов (то есть в Redis в вашем случае). Сохраняется представление самого сеанса вместе с его атрибутами.
Помимо хранения сеанса, другим важным аспектом управления сеансом является корреляция HTTP-запроса пользователя с сохраненным сеансом. Благодаря поддержке API сервлетов Spring Session за это отвечает HttpSessionIdResolver, и по умолчанию Spring Session использует реализацию на основе файлов cookie, то есть CookieHttpSessionIdResolver. В HeaderHttpSessionIdResolver также есть реализация на основе заголовка HTTP. Я говорю об этом, потому что важно понимать, что хранение сеансов - это разные задачи, которые работают на разных уровнях.
Теперь, что касается CookieHttpSessionIdResolver, он делегирует задачи записи и чтения файлов cookie на CookieSerializer (при этом DefaultCookieSerializer является ... ну, реализацией по умолчанию). В соответствии со своей конфигурацией DefaultCookieSerializer будет учитывать ряд параметров при записи и чтении файлов cookie сеанса, например, имя файла cookie, кодировать ли значение cookie в Base64, использовать ли директиву cookie httpOnly и т.
However, I cannot get server affinity because when I debug a HttpServletRequest as it comes into my Spring app, the HttpServletRequest.getSession().getId() doesn't have the jvmRoute in it (although the hex number matches what I see in Chrome), and this is what I pass to the Talend job.
Это та часть, которую я не понимаю - если вы можете разрешить HttpSession из текущего HttpServletRequest, то вы знаете, к какому jvmRoute он привязан правильно? Это jvmRoute текущей JVM, иначе сеанс не будет разрешен HttpServletRequest, обрабатываемым этой JVM.
Отличие Spring Session от управления сеансами Tomcat заключается в том, что в Tomcat jvmRoute имеет значение проблема, связанная с генерацией идентификатора сеанса, тогда как в Spring Session jvmRoute используется в контексте сериализации файлов cookie сеанса.
Есть ли специальный фильтр, который я могу отладить, который удаляет маршрут из sessionId? Я думаю, что это должно происходить, потому что почему у клиента это должно быть, а у сервера нет?
Другими словами, в Spring, в какой момент HttpSession устанавливается с sessionId из файла cookie, и могу ли я предотвратить сокращение jvmRoute?
В ответ я попытался объяснить, что в Spring Session jvmRoute - это аспект сериализации файлов cookie, поэтому логика, учитывающая настроенный jvmRoute, является частью DefaultCookieSerializer. Но опять же, если вы разрешили сеанс из текущего запроса, вы знаете, к какому jvmRoute он привязан - текущей JVM. Затем вы можете просто добавить его к идентификатору сеанса, прежде чем передавать его нижележащему приложению. Я что-то пропустил?
Да, я вас полностью понимаю. Я могу определить JvmRoute в любом месте кода по имени хоста. Однако sessionId, который я передаю Talend, представляет собой сложную строку, в которой идентификатор HttpSession является только ее частью. Теперь это означает, что мне нужно разделить строку, вставить свой jvmRoute и заново собрать идентификатор. Ничего страшного, это всего лишь несколько строк кода. Однако мы намерены удалить липкие сеансы из нашего приложения в следующем году, поэтому я надеялся, что мне больше не придется возвращаться к этой части кода. Я открыл заявку на Spring, чтобы посмотреть, смогут ли они реализовать то, что я хотел.
Поскольку это проблема Spring Session, вы должны открывать билет в Система отслеживания проблем Spring Session, а не в Spring Data Redis. Не стесняйтесь давать ссылку на этот вопрос.
Я понимаю, о чем вы говорите, но причина, по которой я хочу, чтобы jvmRoute был добавлен к сеансу, заключается в том, что я передаю его в виде строки в Talend (с использованием скриптов), этот jvmRoute используется моим talend, чтобы делать больше вызовов моему приложению. Мне нужна привязка к серверу, потому что есть некоторые сгенерированные файлы, хранящиеся локально.