<div class="gmail_quote">2010/5/6 nickmz <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Использую связку Nginx + Tomcat/APR - все работает замечательно, спасибо большое за NGINX.<br>
<br>
Однако есть следующая забота. При деплое новой версии приложения приходится перезагружать Tomcat, при этом NGINX выдает заранее заготовленную страничку с информацией о том, что на сервисе ведутся технические работы. Сам редеплой достаточно быстрый - не более минуты.<br>
<br>
Есть ли возможность (я сам не нашел) попросить NGINX попридержать запросы на какое-то время (заданное в таймауте) - пока сервер приложений отсутствует на время перезагрузки? В этом случае клиентский запрос просто "зависнет" на это время, после чего продолжит работу, когда сервер приложений вновь станет доступным.<br>
</blockquote><div><br>Если tomcat входит в качестве веб-сервера / коннектора в какой-то из "полноценных" серверов приложения (JBoss/Geronimo WebSphere / Glassfish...), то вроде правильнее для такой задачи организовать кластер. На выбор: или на уровне нескольких серверов приложений (несколько tomcat /AppServer), или же на уровне самого приложения (когда "кластеризация" выполнена на уровне программной логики - bean / jms / share каких-то состояний, при этом коннектор /веб -сервер общий).<br>
<br>Далее, несколько вариантов <br>1. [между серверами приложений] шарите данные сессии между экземлярами кластера, и тогда можете относительно спокойно "выключать" обновляемый экземляр, данные текущих сессий будут восстановлены / подхвачены вторым экземляром. <br>
2. [между серверами приложений] отключаете прием новых соединений на обновляемый экземляр, ждете, пока все сессии этого экземляра будут обработаны, после этого спокойно выключаете / обновляете. <br>3. [приложение] принимающий запросы (load-balancing) код не изменился, и он (внутри приложения) "раздает" (неважно каким образом...) запросы между пулом обрабатывающих запросы bean / компонентами. Здесь аналогично "ждете" (слушая по JMX), когда bean освободится и выгружаете соответствующие ejb/ear... При подгрузке же компонент должен обратно зарегистрировать себя в пуле, и дальше сможет получать новые запросы. <br>
<br>В случае если у вас stateless обработка - все становится еще проще. Вам не нужно "шарить сессии" и вся работа заключается максимум - в дождаться пока текущие "короткие" запросы будут обработаны. Хотя можно (при должной организации клиентской части) - и отключить обработку отправив какой-то из правильных статусов... для перезапроса от клиента. <br>
<br><br>2010/5/6 Daniel Podolsky <span dir="ltr"><<a href="mailto:onokonem@gmail.com">onokonem@gmail.com</a>></span> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>другие роботы должны корректно обрабатывать 500 сами. </blockquote><div><br>Для правильных роботов/агентов, вероятно, лучше не 500, а что-то другое... <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
а человеку лучше<br>
показать "приходите через минуту", чем мариновать его эту минуту.<br>
Представляете, сколько раз он за эту минуту нажмет релоад?<br></blockquote><div><br>Это зависит от организованной на UI usability...<br>Вспомните rapidshare. Вы не жмете релоад (пока вам пишут - ждите 10, 9... секунд), потому что это бесполезно....<br>
Если "похожее" сообщение будет у пользователя, он тоже не будет жать Reload. Далее, если клиентское приложение а-ля Rich (Comet / что-то другое), то страница (продложение обработки) может быть возобновлена автоматически - по аналогии как это на gmail ("trying to connect"). <br>
<br>Так что не все тут плохо с usability. <br><br></div><div>
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Если в текущий момент нагрузка составляет 20 запросов в секунду, то за
60 секунд на пуле Nginx накопится очередь в 1200 запросов - и если
подать их все сразу, то 900 запросов будут отклонены, что тоже не очень
хорошо. Видимо без реализации выходного пула с ограничение на
количество исходящих соединений не обойтись.<br>
<br>
</blockquote><br>да, здесь может понадобиться "какой-то" модуль, но скорее всего он должен "онлайн" "коммуницировать" с самим сервером приложений...
<br></div><br><br><br><br><br> <br><br><br><br><br></div><br></div>-- <br>Best regards,<br> ~ Xasima ~<br>