При инициализации приложения на узле системы еще нет ни каких вызовов, нет объекта куда можно возвращать ошибку. Все приложения без исключений в этом состоянии все пишут в лог
Преимущества в другом — готовый сервис для создания распределенных масштабируемых систем.
Кстати, сколько бы узлов в распределенной системе не было бы, любая ошибка будет зафиксирована и в вызываемом узле и доставлена и зафиксирована в вызывающий узел. А уж как ей распорядится вызывающий узел — это дело программного кода системы. Анализировать и сопоставлять логи на множестве узлов не нужно.
Используемая система логирования достаточно гибкая, можно настроить вывод в отдельный лог для событий отдельного экземпляра объекта (такого решения ни где нет).
Сообщения информативны и однозначны.
В промышленных системах система диагностики "многоярусная", ошибка находиться и устраняется.
Это не существенный вопрос. Да использовать при многопоточном доступе к экземпляру этого объекту — нельзя. Если посмотреть исходный код экого класса, то ничего особенного в нем нет.
В промышленных системах править исходный код, где цена ошибки может принести огромные убытки? Любого просто не подпустят! А править конфиг может (и это его обязанность) администратор системы.
"Не удачный" — не видел больших корпоративных систем на PHP. Отдельные небольшие задачи, что когда называлось АРМами — да сколько угодно. Не это не является проблемой, интегрироваться можно и вашей задачей.
Польза, далее реализованная интеграция доступна "везде"
В приведенном примере нет параллельного доступа к объекту Hashtable. В случае одновременного обращения нескольких пользователей каждый будет работать со своим экземпляром Hashtable
Поможет, консистентность данных здесь вообще ни причем. Два узла системы при разнесении на них разных ее "частей" по "определению" имеют разное состояние.
Правда, правда. Обновление узлов системы не критично.
Не приходилось! А мое утверждение — постоянно, когда речь заходит о какой либо модификации кода находящегося в эксплуатации достаточно долгое время. От разных разработчиков, разных контор.
Ваш пример не удачный, PHP мало что умеет и "предложить" ему что вне его рамок, думаю дело гиблое. Но и в этом случае, вариантов решений много.
Например, можно написать специализированный коннектор (в терминах Avalanche — application framework for Java).
<connector class="my.package.JSONСonnector" ...
<publish name ... />
</connector>
А вот здесь вам поможет еще одно замечательное свойство предложенного решения — режим разноверсионности, когда процесс обновления программного обеспечения на разных узлах системы может быть растянут по времени. Это не критично для системы.
Не важно, какой язык Вы используете, важно трудаемкость процесса. Сколько строк кода Вам потребуется вычистить в случае отключения какой то части системы? Вы уверены, что сможете сделать это без ошибок? А вам не приходилось слышать, что "этот код написан очень давно и никто толком не помнит как он работает и лучше его не трогать"?
Прокол Вам не нужно "изобретать". Над вопросами надежности Вам не нужно задумываться, предложенный фреймворк решит эту задачу за Вас. Система логирования уже в комплекте. Система мониторинга в комплекте и способна снять "мерки" с вызова любой функции, которую вы еще только напишите.
Разница огромная! Для изменения конфигурацию достаточно любого текстового редактора. Для приведенного примера достаточно закомментарить или удалить секцию конфигурации. А что нужно для внесения изменений ПО, потрудитесь описать.
При инициализации приложения на узле системы еще нет ни каких вызовов, нет объекта куда можно возвращать ошибку. Все приложения без исключений в этом состоянии все пишут в лог
Наши разные взгляды на обязанности администратора системы выходят за рамки рассматриваемой теме
Преимущества в другом — готовый сервис для создания распределенных масштабируемых систем.
Кстати, сколько бы узлов в распределенной системе не было бы, любая ошибка будет зафиксирована и в вызываемом узле и доставлена и зафиксирована в вызывающий узел. А уж как ей распорядится вызывающий узел — это дело программного кода системы. Анализировать и сопоставлять логи на множестве узлов не нужно.
Используемая система логирования достаточно гибкая, можно настроить вывод в отдельный лог для событий отдельного экземпляра объекта (такого решения ни где нет).
Сообщения информативны и однозначны.
В промышленных системах система диагностики "многоярусная", ошибка находиться и устраняется.
Это не существенный вопрос. Да использовать при многопоточном доступе к экземпляру этого объекту — нельзя. Если посмотреть исходный код экого класса, то ничего особенного в нем нет.
Администратор не программист, в его обязанностях нет пункта править код информационной системы.
Это всего лишь пример. В однопоточном варианте класс отлично работает. И даже в документации JDK 13 нет упоминания, что этот класс @Deprecated
В промышленных системах править исходный код, где цена ошибки может принести огромные убытки? Любого просто не подпустят! А править конфиг может (и это его обязанность) администратор системы.
Модель распространения пока не выбрана. Но если Вас заинтересовал этот продукт давайте обсудим это в личных контактах.
"Не удачный" — не видел больших корпоративных систем на PHP. Отдельные небольшие задачи, что когда называлось АРМами — да сколько угодно. Не это не является проблемой, интегрироваться можно и вашей задачей.
Польза, далее реализованная интеграция доступна "везде"
В логе будет зафиксировано предупреждение
SYS0103W Экземпляр класса "ru.funsys.demo.avalanche.DemoAdapterr" узла <adapter> не создан (класс не найден).
В приведенном примере нет параллельного доступа к объекту Hashtable. В случае одновременного обращения нескольких пользователей каждый будет работать со своим экземпляром Hashtable
Поможет, консистентность данных здесь вообще ни причем. Два узла системы при разнесении на них разных ее "частей" по "определению" имеют разное состояние.
Правда, правда. Обновление узлов системы не критично.
Конфигурацию может поправить любой специалист.
У Вас такой не найдется
Может. 100% выполнить эту операцию без ошибки.
Не приходилось! А мое утверждение — постоянно, когда речь заходит о какой либо модификации кода находящегося в эксплуатации достаточно долгое время. От разных разработчиков, разных контор.
Ваш пример не удачный, PHP мало что умеет и "предложить" ему что вне его рамок, думаю дело гиблое. Но и в этом случае, вариантов решений много.
Например, можно написать специализированный коннектор (в терминах Avalanche — application framework for Java).
Реализовать класс приложения
Вариантов много
А вот здесь вам поможет еще одно замечательное свойство предложенного решения — режим разноверсионности, когда процесс обновления программного обеспечения на разных узлах системы может быть растянут по времени. Это не критично для системы.
Не важно, какой язык Вы используете, важно трудаемкость процесса. Сколько строк кода Вам потребуется вычистить в случае отключения какой то части системы? Вы уверены, что сможете сделать это без ошибок? А вам не приходилось слышать, что "этот код написан очень давно и никто толком не помнит как он работает и лучше его не трогать"?
Занимаюсь сразу обеими задачами, они одинаковы. Одна задача, является частным случаем другой.
Прокол Вам не нужно "изобретать". Над вопросами надежности Вам не нужно задумываться, предложенный фреймворк решит эту задачу за Вас. Система логирования уже в комплекте. Система мониторинга в комплекте и способна снять "мерки" с вызова любой функции, которую вы еще только напишите.
Разница огромная! Для изменения конфигурацию достаточно любого текстового редактора. Для приведенного примера достаточно закомментарить или удалить секцию конфигурации. А что нужно для внесения изменений ПО, потрудитесь описать.