"Провесить" сообщение об ошибке мало, нужно делать это без просадки производительности, а это невозможно делать без контроля состояния узлов системы даже чужих и ваши балансировщики этом не помощники, а только "вредители".
А с чужим узлом — главное чтобы проблема чужого узла не сказывалась на моей системе. Ошибка будет доставлена до пользователя, который может уже предметно разговаривать с техподдержкой, или до фонового процесса который может принять "собственное" решение, что ему делать (например, "заснуть" на некоторое время, "вывесить"а красный флаг в системе мониторинга и т.п.).
Не у меня, там где работаю мои системы да — свои каналы, свои хранилища, свои ЦОДы, своя электроэнергия на случай отсутствия ее в "розетке". Микросхемы вот чужие.
Вы частично уже сами ответили на этот вопрос — предложенное решение может, пусть (даже соглашусь, что "чуть"), "чуть больше" конкурентных технологий. Пример рассмотренного приложения демонстрирует распределенное приложение при минимуме кодирования и предоставляет готовый к использованию "сервис".
В предложенном решении — это не имеет значения (поставщик или потребитель). Предложенное решение позволяет реализовывать распределенные или кластерные приложения, т.е создавать приложение, работающие на множестве узлов — это просто одно приложение.
так функция вызывается с другого узла, ее нет на вызывающем узле. Вызывающий узел не знает какой класс он вызывает. Он знает узел к которому он должен обратиться, имя экземпляра и метод который вызывается. Остальное его "не интересует". Аналогично вызывается и локальный объект.
серьезно, утверждаю
продолжаю утверждать. Только не нужно начинать дискуссию по этому вопросу заново. Здесь "все ходы записаны".
Нет, Вы опять не поняли.
"Провесить" сообщение об ошибке мало, нужно делать это без просадки производительности, а это невозможно делать без контроля состояния узлов системы даже чужих и ваши балансировщики этом не помощники, а только "вредители".
моя не будет, при вашем подходе — ваша будет
так нет проблем с конфигами
Это уже не имеет значения
А с чужим узлом — главное чтобы проблема чужого узла не сказывалась на моей системе. Ошибка будет доставлена до пользователя, который может уже предметно разговаривать с техподдержкой, или до фонового процесса который может принять "собственное" решение, что ему делать (например, "заснуть" на некоторое время, "вывесить"а красный флаг в системе мониторинга и т.п.).
это уже не имеет значения.
что я могу сделать, если Вы все время смотрите только на один узел, а не на множество.
Не у меня, там где работаю мои системы да — свои каналы, свои хранилища, свои ЦОДы, своя электроэнергия на случай отсутствия ее в "розетке". Микросхемы вот чужие.
Вы частично уже сами ответили на этот вопрос — предложенное решение может, пусть (даже соглашусь, что "чуть"), "чуть больше" конкурентных технологий. Пример рассмотренного приложения демонстрирует распределенное приложение при минимуме кодирования и предоставляет готовый к использованию "сервис".
Кто мне мешает? Могу и построил, на своих технологиях.
Я уже понял, что обсуждаемый вопрос выходит за рамки ваших взглядов.
С "чужим" нельзя, со своим можно. Зная что чужой узел не доступен, можно вообще не обращаться к нему, пока он снова не станет работоспособным.
Это конфигурации двух разных узлов одного приложения. Приложение одно, код на узлах одинаковый.
Не верно! При контроле состояния "чужих" узлов можно избежать ухудшения производительности.
В предложенном решении — это не имеет значения (поставщик или потребитель). Предложенное решение позволяет реализовывать распределенные или кластерные приложения, т.е создавать приложение, работающие на множестве узлов — это просто одно приложение.
Значит ваше приложение будет проседать в производительность когда "чужие узлы не доступны"
так функция вызывается с другого узла, ее нет на вызывающем узле. Вызывающий узел не знает какой класс он вызывает. Он знает узел к которому он должен обратиться, имя экземпляра и метод который вызывается. Остальное его "не интересует". Аналогично вызывается и локальный объект.
Верно, не обязательно, но контролировать "чужие" узлы все равно обязаны
там же сеть комментарий выше над этой конфигураций, там написано что должно быть в удаленном коннекторе.
Описано это и в статье