#java #web-applications
#java #веб-приложения
Вопрос:
Я хотел бы запустить веб-контейнер, где каждое веб-приложение выполняется в своем собственном процессе (JVM). Входящие запросы пересылаются прокси-веб-приложением, работающим на порту 80, отдельным веб-приложениям, каждое из которых (webapp) выполняется на своем собственном порту в своей собственной виртуальной машине.
Это решит три проблемы:
- Веб-приложения, использующие JNI (где код JNI изменяется между перезапусками), не могут быть перезапущены. Невозможно гарантировать, что старое веб-приложение было очищено от мусора перед загрузкой нового веб-приложения, поэтому, когда код вызывает System.LoadLibrary(), JVM выдает:
java.lang.UnsatisfiedLinkError: Native Library x already loaded in another classloader. - Библиотеки пропускают память каждый раз при перезагрузке веб-приложения, что в конечном итоге приводит к полному перезапуску сервера. Tomcat добился прогресса в решении этой проблемы, но она никогда не будет полностью исправлена.
- Более быстрые перезапуски. Механизм, который я предлагаю, позволил бы почти мгновенный перезапуск веб-приложения. Нам больше не нужно ждать завершения выгрузки старого веб-приложения, что является самой медленной частью.
Я разместил RFE здесь и здесь. Я хотел бы знать, что вы думаете.
Делает ли это какой-либо существующий веб-контейнер сегодня?
Ответ №1:
Я закрываю этот вопрос, потому что, похоже, я зашел в тупик: http://tomcat.10.n6.nabble.com/One-process-per-webapp-td2084881.html
В качестве обходного пути я вручную запускаю отдельный экземпляр Jetty для каждого веб-приложения.
Ответ №2:
Разве вы не можете просто развернуть по одному приложению на контейнер, а затем использовать записи DNS и обратные прокси, чтобы сделать то же самое? Я полагаю, что у Weblogic есть нечто подобное в виде управляемых доменов.
Комментарии:
1. предоставляя единый интерфейс управления для нескольких веб-приложений, вы могли бы повысить производительность, которая сегодня невозможна при использовании отдельных контейнеров. Например: когда пользователь просит перезагрузить веб-приложение, вы могли бы предварительно загрузить веб-приложение без контейнера, простаивающее в фоновом режиме. Когда поступают запросы на перезагрузку, вы просто выключаете старую JVM и загружаете новое веб-приложение в ожидающую JVM. Если бы я должен был реализовать это сегодня, завершение работы экземпляра и повторный запуск его последовательно заняли бы намного больше времени (и, следовательно, снизили бы производительность разработки).
Ответ №3:
Нет, AFAIK, ни один из них этого не делает, вероятно, потому, что веб-контейнеры Java подчеркивают важность следования servlet API, который запускает поток для каждого http-запроса. То, что вы хотите, было бы форком на уровне JVM — и это просто не стандартная идиома Java.
Комментарии:
1. Я не прошу каждый http-запрос запускаться в его собственной JVM. Я изолирую каждое веб-приложение в его собственной JVM, а не каждый запрос одного и того же веб-приложения.
Ответ №4:
Если я правильно понимаю, вы запрашиваете стандартные функции для серверов корпоративного качества, таких как IBM WebSphere Network Deployment (отказ от ответственности, я работаю в IBM), где вы можете распространять приложения по многим JVM, и эти JVM фактически могут быть распределены по многим физическим машинам.
Однако я не уверен, что ваша фундаментальная предпосылка верна. Нет необходимости перезапускать всю JVM, чтобы развернуть новую версию приложения. Многие серверы приложений будут использовать стратегию загрузки классов, которая позволяет им отбрасывать версию приложения и загружать новую.
Комментарии:
1. Вы неправильно поняли мой вопрос. Мне не не нужно веб-приложение для работы с JVMS. Насколько я знаю, не существует безопасного способа перезапуска приложения JNI, кроме перезапуска всей JVM, поэтому специальная стратегия загрузки классов здесь не сработает.