У меня есть пара серверов tomcat, сидящих за сервером apache, на котором запущен modjk2. нагрузка на сервер Apache балансирует сеансы с серверами Tomcat (используя x.sticky_session=True). Все это работает нормально, однако мы хотели бы иметь возможность устанавливать новый код на серверы tomcat без завершения каких-либо сеансов.
Мы не можем использовать сериализацию сеанса tomcat, поскольку не все сохраненные объекты сериализуемы, и время простоя может быть слишком долгим.
В настоящее время мы отключаем TomcatA (фактически уничтожая все его текущие сеансы), устанавливаем на него новый код, запускаем его, а затем, когда apache начинает маршрутизировать запросы обратно к нему, делаем то же самое на TomcatB.
Что мы хотели бы сделать, так это отключить новые сеансы на TomcatA (и, возможно, сократить срок жизни существующих сеансов), а затем, когда все его сеансы истекли, выключить его, чтобы выполнить установку .., а затем то же самое для TomcatB.
Кто-нибудь решил подобную проблему или есть какие-либо советы относительно такой настройки? В настоящее время я не уверен, должны ли apache или tomcat нести ответственность за запрет новых сеансов ...
С уважением, Пол.
Похоже, что установка activation параметр на работнике должен помочь ... установив для него значение disabled должен продолжать обслуживать существующие сеансы, но не направлять запросы новых сеансов отключенному работнику.
Мы собираемся объединить это с трансляцией в нашем приложении j2ee, чтобы пользователи могли сохранить свою работу, выйти из системы и снова войти в систему.
Как только количество активных сеансов достигнет приемлемо низкого уровня, мы отключим экземпляр tomcat для обновлений, затем запустим его и повторим для другого сервера tomcat.
Это всего лишь план, но на данный момент мне кажется выполнимым, я бы признателен за ваше информированное мнение, прежде чем я закрою этот вопрос.
Спасибо, Пол.
Вы после чего-то, что называется "хромое пригнувшись".
Вы можете проверить работоспособность запросов балансировщиков нагрузки, проверив конкретный URL-адрес на бэкэнде. У вас есть способ сказать серверной части, что этот URL-адрес не работает, пока он обслуживается.
В идеале этот URL-адрес отличается от того, что ваша система наблюдения использует для отслеживания автоматического перезапуска процесса. Это может быть так же просто, как добавить ?query на обычный URL-адрес проверки работоспособности.
Через короткий промежуток времени балансировщики нагрузки выкинут серверную часть жертвы из обслуживающего пула, и существующие соединения будут завершены; то, как вы обрабатываете буферизацию во внешнем интерфейсе и медленные клиенты, будет влиять на то, сколько времени это займет, но это является стимулом для обработки статических ресурсов отдельным сервером. :)
Затем вы можете обновить бэкэнд.