Есть некая система (библиотека). Одна из ее составных частей — уровень провайдеров данных.
Для провайдера введено такое понятие как "health status". В общем случае, health status это некая информация, характеризующая текущее состояние провайдера (StatusCode и StatusText).
Провайдер может быть в одном из трех состояний:
1. Зеленое — Все нормально. Соединение с источником данных есть (или что-то типа этого).
2. Желтое — Внимание. Была ошибка при доступе к источнику, но теперь соединение восстановлено (или что-то типа этого).
3. Красный — ошибка при доступе к источнику данных (или что-то типа этого).
Из состояния 2 ожидается переход либо в состояние 1, либо 3.
Провайдер должен поддерживать информацию о своем health status наряду с обработкой/выкидыванием эксепшенов.
Мне не совсем очевидно как увязать между собой эти две вещи. Может кто-нить подскажет пример где позожая конценпция уже реализована. Или что-нить типа guidelines по имплементации чего-нить типа health status'а.
Здравствуйте, <Аноним>, Вы писали:
А>Сомневаюсь что конечный автомат здесь может чем-то помочь )
А>Переход мнжду состояниями здесь отнюдь не самое важное и сложное.
А>Вопрос в том как грамотно это увязать с exception handling чтобы работало и то, и другое
В чем собственно сложность? Посмотрим, что случилось бы, если б вы последовали совету выше. Открываем GoF на странице 291 и читаем про паттерн State:
Используйте паттерн состояние в следующих случаях:
когда поведение объекта зависит от его состояния и должно изменяться во время выполнения;
...
Кроме того, GoF приводят пример чуть не один в один с вашим: на диаграмме классов TCPConnection, абстрактное состояние TCPState и его наследники, ровно 3, как и у вас: TCPEstablished, TCPListen, TCPClosed.
PS Можно почитать про шаблон проектирования State в статьях этого ресурса.
Здравствуйте, rsn81, Вы писали:
R>В чем собственно сложность? Посмотрим, что случилось бы, если б вы последовали совету выше. Открываем GoF на странице 291 и читаем про паттерн State:Используйте паттерн состояние в следующих случаях:
когда поведение объекта зависит от его состояния и должно изменяться во время выполнения;
...
У меня поведение объекта не зависит и не должно меняться в зависимости от его состояния.
Просто на ряду с тем, что объект должен хэндлить возможные эксепшены, он также должен иметь возможность "рассказать" о своем состоянии (по запросу).
Естесственно, та информация, которую он должен выдать в ответ на запрос о своем состоянии будет изменяться в зависимотси от того, к примеру, было ли посленее чтение из источника данных успешным.
Думаю что применение паттерна только усложнит ситуацию в данном случае.
Здравствуйте, Аноним, Вы писали:
А>Есть некая система (библиотека). Одна из ее составных частей — уровень провайдеров данных.
А>Для провайдера введено такое понятие как "health status". В общем случае, health status это некая информация, характеризующая текущее состояние провайдера (StatusCode и StatusText).
А>Провайдер может быть в одном из трех состояний:
Это не состояние провайдера, а сигнал, который он выдаёт.
А>1. Зеленое — Все нормально. Соединение с источником данных есть (или что-то типа этого).
А>2. Желтое — Внимание. Была ошибка при доступе к источнику, но теперь соединение восстановлено (или что-то типа этого).
А>3. Красный — ошибка при доступе к источнику данных (или что-то типа этого).
А>Из состояния 2 ожидается переход либо в состояние 1, либо 3.
А что, можно куда-нибудь ещё?
Короче, профессор не прав, всё не так было.
Есть множество контролируемых параметров системы. Для каждого параметра, кроме состояния Unknown определены диапазоны значений, к которым привязаны оценки: OK, Warning, Failed. Соответсвенно, health monitor (HM) может по результатам анализа выставить один из трёх сигналов:
Зелёный — все параметры OK;
Жёлтый — как минимум один параметр оценен как Warning;
Красный — как минимум один параметр оценен как Failed.
Индукции могут быть и другими, например "Красный" сигнал может выдаваться, если все параметры некоторой группы стали Failed.
Что это за параметры, как они вычисляются и т.п. — решается по месту, для данной системы. Допустим, ты контролируешь состояние какого-то потока по критериям: а) существования и б) загрузки CPU. Соответственно, нужно периодически проверять валидность соответствующего ThreadID: есть такой поток — OK, нет — Failed (Warning тут, очевидно, не возможен). И ещё, нужно смотреть на CPU Loading, это можно вычислять в самом потоке — обращением к ОС. Здесь уже возможны вариации, например: 0-70% — OK, 71%-85% — Warning, >85% — Failed.
Дальше HM анализирует все параметры и вычисляет значение итогового сигнала, плюс выдаёт список самих параметров и их оценок.
А>Провайдер должен поддерживать информацию о своем health status...
Периодически сканирует своё состояние, оценка выводится по общим принципам.
А>наряду с обработкой/выкидыванием эксепшенов.
Интересно, а запас эксепшенов у HM большой? Не кончатся по ходу дела?
Сомнительная затея — передавать HM ексепшены. Ты с логом HM не путаешь, нет? Приложение может выдать монитору сигнал о том, что какая-то подсистема, например ушла в down; HM выдаст соответвующий сигнал пользователю, если он сам располагает описанием соответствующего сигнала и "знает", как его обработать.
А>Мне не совсем очевидно как увязать между собой эти две вещи. Может кто-нить подскажет пример где позожая конценпция уже реализована. Или что-нить типа guidelines по имплементации чего-нить типа health status'а.
Поищи по ключевым словам "system health monitoring". То, что я тут написал, только верхушка айсберга, вариантов много, вплоть до размещения монитора на отдельной машине. Кратко требования: собственная надёжность и минимум влияния на окружающую систему (т.е. min памяти, min CPU).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
А>>Из состояния 2 ожидается переход либо в состояние 1, либо 3.
ГВ>А что, можно куда-нибудь ещё?
Ну может остаться в состоянии 2 )
ГВ> Короче, профессор не прав, всё не так было.
ГВ>Есть множество контролируемых параметров системы. Для каждого параметра, кроме состояния Unknown определены диапазоны значений, к которым привязаны оценки: OK, Warning, Failed. Соответсвенно, health monitor (HM) может по результатам анализа выставить один из трёх сигналов:
ГВ>Зелёный — все параметры OK;
ГВ>Жёлтый — как минимум один параметр оценен как Warning;
ГВ>Красный — как минимум один параметр оценен как Failed.
Все так и есть
[]
А>>Провайдер должен поддерживать информацию о своем health status...
ГВ>Периодически сканирует своё состояние, оценка выводится по общим принципам.
по идее, можно и без периодического сканирования. т.к. информацию о health status провайдер должен выдавать по специальному запросу, то и собрать ее можно в момент запроса.
А>>наряду с обработкой/выкидыванием эксепшенов.
ГВ>Интересно, а запас эксепшенов у HM большой? Не кончатся по ходу дела?
ГВ>Сомнительная затея — передавать HM ексепшены. Ты с логом HM не путаешь, нет? Приложение может выдать монитору сигнал о том, что какая-то подсистема, например ушла в down; HM выдаст соответвующий сигнал пользователю, если он сам располагает описанием соответствующего сигнала и "знает", как его обработать.
Может я не так выразился. Я имел ввиду, что например, при доступе к файлу на диске возможно будет выброшен эксепшн. Который система, естессно, должна хэнжлить. + Параллельно этому данная ситуация (с выброшенным эксепшеном) должна отразиться на текущем health status'е. вот я и ищу какой-нить красивый способ это увязать.
А>>Мне не совсем очевидно как увязать между собой эти две вещи. Может кто-нить подскажет пример где позожая конценпция уже реализована. Или что-нить типа guidelines по имплементации чего-нить типа health status'а.
ГВ>Поищи по ключевым словам "system health monitoring". То, что я тут написал, только верхушка айсберга, вариантов много, вплоть до размещения монитора на отдельной машине. Кратко требования: собственная надёжность и минимум влияния на окружающую систему (т.е. min памяти, min CPU).
Ок. Спасибо!
