ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
8 сообщений из 8, страница 1 из 1
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37597740
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
junixar
Участник
Задача:

сервер работает с удалённым агентом. Обмен осуществляется с помощью асинхронных сообщений. В принципе сейчас логика обмена подразумевает, что сервер шлёт агенту сообщения с какой-то задачей и агент по результатам выполнения задачи, успешным или не успешным отправляет обратное сообщение. Т.е. всегда есть первое сообщение от сервера и ответ от агента.

Задачи могут быть длительными - часы и дни.

И вот в чём проблема. Если вдруг агент недоступен, то сервер может об этом и не узнать. Сообщение просто не дойдёт до агента, а сервер будет бесконечно ждать ответа.

Вижу три возможных варианта решения:

1. Изменить логику общения. Когда сервер ждёт не только ответа, а и подтверждения, что задача начала обрабатываться. И тут ввести Timeout, сколько сервер ждёт этого подтверждения. Можно и усложнить, когда сервер на протяжении всего выполнения задачи должен периодически получать уведомления, что задача выполняется.

2. Сервер периодически опрашивает агента на предмет его работоспособности по разным пунктам, в синхронном режиме. И учитывает последнюю сводку для новых задач или уже поставленных на выполнение.

3. Агент сам периодически шлёт сводку своей работоспособности. Вроде вариация пункта два, но во первых агент ничего не знает, работает ли сейчас сервер, нужен ли серверу сейчас этот агент и будет просто рассылать быть может ненужную информацию.

Сам больше склоняюсь к вариантам 1 или 2, но пока не могу выбрать. Но с другой стороны, гораздо проще реализовать вариант 3.

Кто что скажет? Может по опыту или какие-то ещё будут мысли.

Всем заранее спасибо.
...
Рейтинг: 0 / 0
28.12.2011, 18:26
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37597837
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Начните с ответа на вопрос - какие действия и кто должен будет предпринять, обнаружив неработоспособность агента.

Лично я в своей практике применял два подхода:

Сервер периодически посылает агентам "пинги" - то есть тривиальные задачи, вся обработка которых сводится к возврату ответа.

Независимый монитор, которые собирает ключевые показатели с сервера, с агентов и с прочих интересующих меня объектов и пишет alarm-ы на заданные критические условия (just for example, timestamp последней задачи, посланной сервером - timestamp последней задачи, обработанной агентом, больше 10 минут).
...
Рейтинг: 0 / 0
28.12.2011, 19:27
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37598258
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
junixar
Участник
В случае, если агент недоступен или работает в чём-то некорректно, то как правило нужно все запущенные уже на нём задачи перенести (запустить заново) на другого агента, если такая возможность для этих задач есть. Новые задачи на этом "плохом" агенте не должны запускаться, пока он не восстановится.

Но бывают случаи, когда агент сломался лишь частично и можно попробовать перезапустить на нём задачу или перезапустить с несколько другими параметрами. Правда такие случаи надо ещё правильно распознать.
...
Рейтинг: 0 / 0
29.12.2011, 01:43
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37598261
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
junixar
Участник
Плюс для всех новых задач, которые появятся уже позже, надо точно знать, восстановился ли агент или на него всё ещё нельзя рассчитывать.

Поэтому я больше склоняюсь к некоему общему варианту 1+2.
...
Рейтинг: 0 / 0
29.12.2011, 01:45
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37598497
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
junixar,
всё уже придумано.
Взять за основу Job в оракле напр.
Там есть всё. И мониторинг, и перезапуск, и текущий статус....
...
Рейтинг: 0 / 0
29.12.2011, 10:03
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37598590
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
junixar
Участник
Petro123, что вы имеете в виду? Какой именно продукт Oracle?
...
Рейтинг: 0 / 0
29.12.2011, 10:48
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37599203
WebPrj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WebPrj
Гость
junixarPetro123, что вы имеете в виду? Какой именно продукт Oracle?
технологически и по интерфейсу Job работает согласно вашему ТЗ.
Почитайте немного о нём в гугле и сделайте так-же.
Т.е. сначала найди аналогичные решения в соседних областях.
...
Рейтинг: 0 / 0
29.12.2011, 15:28
| Ответить | Цитировать | Написать  
Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
    #37599238
WebPrj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WebPrj
Гость
junixarЗадачи могут быть длительными - часы и дни.

вот, например, мониторинг длит.задачи
Monitoring job-scheduling
Jobs can be monitored using Oracle Enterprise Manager 10g. It's also possible to use a number of views that have been created in Oracle 10g. We will discuss some of these views here.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
To show details on job run:
select log_date
,      job_name
,      status
,      req_start_date
,      actual_start_date
,      run_duration
from   dba_scheduler_job_run_details
  
To show running jobs:
select job_name
,      session_id
,      running_instance
,      elapsed_time
,      cpu_used
from dba_scheduler_running_jobs;
  
To show job history:
 select log_date
 ,      job_name
 ,      status
 from dba_scheduler_job_log;
 
 
show all schedules:
select schedule_name, schedule_type, start_date, repeat_interval 
from dba_scheduler_schedules;
 
show all jobs and their attributes:
select *
from dba_scheduler_jobs
 
 
show all program-objects and their attributes
select *
from dba_scheduler_programs;
 
show all program-arguments:
select *
from   dba_scheduler_program_args;
...
Рейтинг: 0 / 0
29.12.2011, 15:42
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Как лучше реализовать диагностирование удалённых проблем при асинхронном обмене?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=33&msg=37597740&tid=1547926]:
 0ms
get settings:
 9ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 36ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 37ms
get tp. blocked users:
 1ms
others: 14ms
total:  126ms
созд. / загр.: 126ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]