Горячий развертывают Java EAR, чтобы минимизировать или устранить время простоя приложения на сервере?

Question

Горячий развертывают Java EAR, чтобы минимизировать или устранить время простоя приложения на сервере?

Попробуйте использовать:

data = [d.strip() for d in response.css('.txt-block::text') if d.strip()]

данные, которые вы хотите, фактически находятся в теге div, и я использую этот тег для получения данных.

7

jboss deployment java

задан Ichorus 21 October 2008 в 13:17

4 ответа

Поскольку я понимаю, что WebLogic имеет функцию, названную параллельным развертыванием для устранения времени простоя во время обновления версии EAR. Можно развернуть новую версию, не останавливая существующее приложение и однажды новая версия, развернутая успешно, можно переключиться прозрачно от старого до нового.

Я не уверен, поддерживает ли другой сервер приложений это.

Касательно: http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1022490

1

ответ дан 7 December 2019 в 07:52

Предложение Vladimir вокруг использования подсистемы балансировки нагрузки является вполне уверенным способом достигнуть того, что Вы хотите. Следует иметь в виду, это не должна обязательно быть высокопроизводительная аппаратная подсистема балансировки нагрузки. Скорее при противостоянии на сервер JBoss с собственным веб-сервером (Apache или IIS) и mod_jk или mod_proxy можно поддержать один общий веб-фасад и реализовать применимую загрузку и маршрутизацию стандартных программ во время обновления EAR.

//Nicholas

1

ответ дан 7 December 2019 в 07:52

Я думаю, что Вы могли бы хотеть изучить Spring с помощью платформы OSGI. http://www.springframework.org/osgi

0

ответ дан 7 December 2019 в 07:52

Другие вопросы по тегам:

jboss deployment java

Похожие вопросы:

score 5 · Accepted Answer

Это не то, что делает JavaRebel. JavaRebel (согласно описанию) горячие замены классы в памяти. Это не приемлемо в случае существующих соединений с системой, так как обновленные классы могут повредить логику клиента.

После того как компания, на которую я работал, имела подобную проблему, и она была решена этот путь:

умный маршрутизатор использовался в качестве подсистемы балансировки нагрузки
новая версия была развернута на 50% узлов (нового) кластера
новые соединения были поставлены строго этим обновленным узлам, старые были сбалансированы между старыми узлами
старые узлы были, вывел из эксплуатации (один за другим, для хранения числа клиентов на узел в определенных рамках)
одновременно, новая версия была развернута на офлайновых "старых" узлах, и они были подняты как новые узлы
из-за кластеризации EJB, сессии и бобы были взяты другими старыми узлами
в конечном счете (за несколько часов), только один старый оставленный узел, имея единственный экземпляр старой версии и всех клиентов, использующих старую версию, был подключен к нему
когда последний старый клиент был разъединен, тот узел был слишком снижен

Теперь, я не сетевой парень и не могу предоставить Вам много подробной информации (как то, что было оборудованием маршрутизатора и таким). Мое понимание этого может быть настроено довольно легкое, если не я помню право, мы должны были установить дополнительный домен Weblogic для развертывания новых версий приложения (иначе, это будет конфликтовать со старым на именах JNDI).

Надежда, которая помогает.

P.S. Ichorus предоставил комментарий, заявив, что приложение развертывается на серверах клиентов. Таким образом, прием маршрутизатора может быть не выполнимым. Теперь, я вижу только одно эффективное решение прямо сейчас (это - 21:52 теперь, я могу пропустить вещи :))-

Разработайте новую версию с "имеющими версию" именами JNDI; например, если бы Клиентский боб находился под ejb/Customer в версии 1, то в версии 2 это находилось бы под ejb/Customer2
Имейте бизнес-фасад в приложении со стабильным основным интерфейсом (стиль Фабрики), который при просьбе относительно Клиентского боба, попытки найти имеющее версию самым высоким образом имя JNDI (не на каждом вызове, конечно, может кэшироваться в течение приблизительно одного часа). Тот фасад мог (и если) быть развернутым как отдельное приложение - и никогда или очень редко не обновляться
Теперь каждый новый клиент получил бы доступ к последнему приложению, развернутому, и приложения не будут конфликтовать.

Этот подход берет тщательное планирование и тестирование, но должен работать, по моему скромному мнению.

Я недавно изменил несколько приложений похожим способом позволить им сосуществовать в том же домене (прежде чем они использовали то же имя JNDI для различных источников данных).