#459 closed баг (fixed)
Программа не выдала ошибку связи с сервером, в момент пропадания связи с сервером
| Reported by: | san | Owned by: | dimag |
|---|---|---|---|
| Priority: | critical | Milestone: | |
| Component: | ПО MC04-Dispatcher. Пульт диспетчера/техника | Keywords: | algorithm, network |
| Cc: |
Description
- Связь с сервером пропала.
- Программа не отобразила аварию (прошло точно больше 10 секунд, а точнее - время включения блока 3U с платой SM-01)
- Программа не реагирует на команды пользователя, но аварию не показывает.
- Соединение восстановилось
- Программа так и не реагирует на команды пользователя (не менее 30 секунд)
- Внезапно программа "ожила" и стала работать как обычно
Дальше исследовал Дмитрий
r473
Change History (29)
comment:1 by , 8 years ago
| Keywords: | algorithm network added |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:2 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Переоткрою по формальной причине: Из описания к комиту и коментарию к тикету не понятно в чём была причина появления деффекта и каким образом её удалось устранить
comment:3 by , 8 years ago
Причина появления дефекта - при обработке запроса от пользователя я определял наличие или отсутствие соединения по наличию физического соединения с компьютерной сетью, а при обработке сообщений я использовал в качестве наличия связи с сервером успешную обработку команды status сервером. Теперь при обработке запроса от пользователя и использую результат выполнения запроса в потоке обработки команд для определения наличия связи с сервером.
comment:4 by , 8 years ago
И по какой причине програма не смогла детектировать отсутствие "соединения" или связи с сервером?
comment:5 by , 8 years ago
Поток обрабатывающий команды пользователя мог иногда неверно определить наличие подключения.
comment:6 by , 8 years ago
Я все-таки не понял, почему отсутствие связи не было обнаружено программой.
Насколько я понял из comment:3 (поправьте меня если я понялнеправильно), в программе реализовано одновременно два независимых механизма определения отсутствия связи с сервером:
- в интерфейсном потоке мониторится наличие линка на интерфейсе ethernet;
- в потоке приема сообщений от FS мониторятся ответы на запросы к FS.
Допустим, выяснилось (comment:5), что первый механизм иногда работал неверно. Но второй-то механизм при этом все равно должен был выполнить свою функцию - по факту отсутствия ответов от FS определить, что с соединением что-то не так... Почему же этого не произошло? Получается, что второй механизм тоже ненадежен и, если так, просто отказавшись от использования первого механизма, мы не получили надежное определение отсутствия связи с сервером...
follow-up: 8 comment:7 by , 8 years ago
Эти проверки были до r480 отдельны для потоков пользовательского ввода и событий. Поэтому была ситуация когда в пользовательском потоке отсутствие соединения определялось ошибочно, а в потоке событий верно. Сейчас отсутствие соединений определяется только в потоке событий. Другие потоки пользуются последним результатом проверки в потоке событий.
comment:8 by , 8 years ago
Replying to dimag:
Эти проверки были до r480 отдельны для потоков пользовательского ввода и событий. Поэтому была ситуация когда в пользовательском потоке отсутствие соединения определялось ошибочно, а в потоке событий верно.
Если в потоке событий отсутствие соединения определялось верно, почему в описанном Александром случае на экране не появилось сообщение об отсутствии связи с сервером?
Сейчас отсутствие соединений определяется только в потоке событий. Другие потоки пользуются последним результатом проверки в потоке событий.
Вы же сами говорите, что оно и раньше в нем определялось. Тем не менее, пользователь не получил уведомление о проблеме.
follow-up: 10 comment:9 by , 8 years ago
В потоке команд до r480 плохо определялась ситуация когда есть физическое соединение с сетью, но не возобновилась связь с FreeSwitch сервером, поэтому не было сообщения о проблеме, теперь алгоритм определения наличия соединения другой, соответственно пропажа соединения обнаружиться.
comment:10 by , 8 years ago
Мы опять ходим по кругу.
Replying to dimag:
В потоке команд до r480 плохо определялась ситуация когда есть физическое соединение с сетью, но не возобновилась связь с FreeSwitch сервером, поэтому не было сообщения о проблеме,
Это объяснение было бы логичным, если бы механизм определения отсутствия связи в пользовательском потоке был единственным: этот механизм работает плохо, поэтому не было индикации. Но мы знаем, что это не так. Вы говорите, что таких механизмов в программе было два: один (работающий плохо) в пользовательском потоке и второй (работающий хорошо) - в потоке событий. Так как второй механизм, по вашему утверждению, работает хорошо, в описанном Александром случае он должен был определить факт отсутствия связи. Тем не менее, сообщения о ее отсутствии программа не выдала. Вопрос почему не было сообщения об отсутствии связи?
Формальная логика заставляет сделать вывод о том, что, раз программа не выдала предупреждение, значит ни один из имеющихся у нее механизмов не обнаружил факт отсутствия связи. Следовательно, второй механизм хорошо работающим считать нельзя.
теперь алгоритм определения наличия соединения другой, соответственно пропажа соединения обнаружиться.
Теперь другой алгоритм где? В каком из двух упомянутых механизмов? В comment:7 Вы пишете:
Сейчас отсутствие соединений определяется только в потоке событий.
Правильно ли я понял, что изменен алгоритм именно второго механизма, работающего в потоке событий? Если да, то непонятно, зачем был изменен алгоритм работы механизма, который, по вашему утверждению, и так работал хорошо и надежно...
follow-up: 12 comment:11 by , 8 years ago
Правильно ли я понял, что изменен алгоритм именно второго механизма, работающего в потоке событий? Если да, то непонятно, зачем был изменен алгоритм работы механизма, который, по вашему утверждению, и так работал хорошо и надежно...
Иногда он не срабатывал,в ситуации когда например FreeSwitch сервер стоял на той машине и программа была запущенна или ситуация когда физическое соединение есть, но FreeSwitch по нему всё равно обнаружить нельзя, так как FreeSwitch в недоступном сегменте сети.
comment:12 by , 8 years ago
Replying to dimag:
Иногда он не срабатывал,
Выяснена ли причина, по которой второй механизм иногда не срабатывал?
follow-up: 14 comment:13 by , 8 years ago
Да.
В первую очередь нужно было ориентироваться на наличие отклика от Freeswitch сервера по запросу status с временем ожидания 200 мс, если данный запрос успешно выполнялся, то считать что соединение существует, если нет, то считать что соединение разорванно и начать пытать восстановить соединение. Я вместо этого сперва ориентировался на наличие хотя 1 физического подключения в сети, особенно в главном потоке приложения.
follow-up: 16 comment:15 by , 8 years ago
Я ориентировался в первую очередь на наличие хотя одного физического соединения с сетью, а надо было ориентироваться на наличие связи с сервером.
comment:16 by , 8 years ago
Replying to dimag:
Я ориентировался в первую очередь на наличие хотя одного физического соединения с сетью,
Верно ли я понял, что наличие физического соединения с сетью проверялось и в пользовательском потоке, и в потоке сообщений?
а надо было ориентироваться на наличие связи с сервером.
Так ведь Вы и так на него ориентировались! В comment:3 Вы писали:
при обработке сообщений я использовал в качестве наличия связи с сервером успешную обработку команды status сервером.
comment:17 by , 8 years ago
Верно ли я понял, что наличие физического соединения с сетью проверялось и в пользовательском потоке, и в потоке сообщений? Да.
comment:18 by , 8 years ago
Верно ли я понял, что ранее (до коммита r480) ни пользовательский поток, ни поток сообщений на наличие связи с сервером не ориентировались?
comment:21 by , 8 years ago
При наличие физического соединения проводилась проверка на наличие связи с сервером.
comment:22 by , 8 years ago
Верно ли я понимаю, что в случае, о котором Александр пишет в описании тикета, произошло следующее:
- Пропало физическое соединение компьютера с сетью (ethernet).
- Так как физического соединения нет, проверка на наличие связи с сервером не производилась и, как следствие, не было индикации отсутствия связи с сервером.
???
comment:24 by , 8 years ago
Хорошо. Правильно ли я понял, что сейчас (начиная с r480) проверка на наличие связи с сервером выполняется независимо от наличия или отсутствия физического соединения?
comment:26 by , 8 years ago
Саша, насколько я понял, проблема выявлена и устранена. Думаю, тикет можно закрыть. Предлагаю тебе принять окончательное решение.
comment:28 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
r480
Определяю наличие подключения только из потока обработки сообщений от FreeSwitch сервера, не ориентируясь на физическое подключение интерфейсов.