Программа не выдала ошибку связи с сервером, в момент пропадания связи с сервером

[san]

1. Связь с сервером пропала.
2. Программа не отобразила аварию (прошло точно больше 10 секунд, а точнее - время включения блока 3U с платой SM-01)
3. Программа не реагирует на команды пользователя, но аварию не показывает.
4. Соединение восстановилось
5. Программа так и не реагирует на команды пользователя (не менее 30 секунд)
6. Внезапно программа "ожила" и стала работать как обычно

Дальше исследовал Дмитрий
r473

[dimag]

r480
Определяю наличие подключения только из потока обработки сообщений от FreeSwitch сервера, не ориентируясь на физическое подключение интерфейсов.

[san]

Переоткрою по формальной причине: Из описания к комиту и коментарию к тикету не понятно в чём была причина появления деффекта и каким образом её удалось устранить

[dimag]

Причина появления дефекта - при обработке запроса от пользователя я определял наличие или отсутствие соединения по наличию физического соединения с компьютерной сетью, а при обработке сообщений я использовал в качестве наличия связи с сервером успешную обработку команды status сервером. Теперь при обработке запроса от пользователя и использую результат выполнения запроса в потоке обработки команд для определения наличия связи с сервером.

[san]

И по какой причине програма не смогла детектировать отсутствие "соединения" или связи с сервером?

[dimag]

Поток обрабатывающий команды пользователя мог иногда неверно определить наличие подключения.

[alx]

Я все-таки не понял, почему отсутствие связи не было обнаружено программой.

Насколько я понял из comment:3 (поправьте меня если я понялнеправильно), в программе реализовано одновременно два независимых механизма определения отсутствия связи с сервером:

1. в интерфейсном потоке мониторится наличие линка на интерфейсе ethernet;
2. в потоке приема сообщений от FS мониторятся ответы на запросы к FS.

Допустим, выяснилось (comment:5), что первый механизм иногда работал неверно. Но второй-то механизм при этом все равно должен был выполнить свою функцию - по факту отсутствия ответов от FS определить, что с соединением что-то не так... Почему же этого не произошло? Получается, что второй механизм тоже ненадежен и, если так, просто отказавшись от использования первого механизма, мы не получили надежное определение отсутствия связи с сервером...

[dimag]

Эти проверки были до r480 отдельны для потоков пользовательского ввода и событий. Поэтому была ситуация когда в пользовательском потоке отсутствие соединения определялось ошибочно, а в потоке событий верно. Сейчас отсутствие соединений определяется только в потоке событий. Другие потоки пользуются последним результатом проверки в потоке событий.

[alx]

Replying to dimag:

Эти проверки были до r480 отдельны для потоков пользовательского ввода и событий. Поэтому была ситуация когда в пользовательском потоке отсутствие соединения определялось ошибочно, а в потоке событий верно.

Если в потоке событий отсутствие соединения определялось верно, почему в описанном Александром случае на экране не появилось сообщение об отсутствии связи с сервером?

Сейчас отсутствие соединений определяется только в потоке событий. Другие потоки пользуются последним результатом проверки в потоке событий.

Вы же сами говорите, что оно и раньше в нем определялось. Тем не менее, пользователь не получил уведомление о проблеме.

[dimag]

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

[alx]

Мы опять ходим по кругу.

Replying to dimag:

В потоке команд до r480 плохо определялась ситуация когда есть физическое соединение с сетью, но не возобновилась связь с FreeSwitch сервером, поэтому не было сообщения о проблеме,

Это объяснение было бы логичным, если бы механизм определения отсутствия связи в пользовательском потоке был единственным: этот механизм работает плохо, поэтому не было индикации. Но мы знаем, что это не так. Вы говорите, что таких механизмов в программе было два: один (работающий плохо) в пользовательском потоке и второй (работающий хорошо) - в потоке событий. Так как второй механизм, по вашему утверждению, работает хорошо, в описанном Александром случае он должен был определить факт отсутствия связи. Тем не менее, сообщения о ее отсутствии программа не выдала. Вопрос почему не было сообщения об отсутствии связи?

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

теперь алгоритм определения наличия соединения другой, соответственно пропажа соединения обнаружиться.

Теперь другой алгоритм где? В каком из двух упомянутых механизмов? В comment:7 Вы пишете:

Сейчас отсутствие соединений определяется только в потоке событий.

Правильно ли я понял, что изменен алгоритм именно второго механизма, работающего в потоке событий? Если да, то непонятно, зачем был изменен алгоритм работы механизма, который, по вашему утверждению, и так работал хорошо и надежно...

[dimag]

Правильно ли я понял, что изменен алгоритм именно второго механизма, работающего в потоке событий? Если да, то непонятно, зачем был изменен алгоритм работы механизма, который, по вашему утверждению, и так работал хорошо и надежно...
Иногда он не срабатывал,в ситуации когда например FreeSwitch сервер стоял на той машине и программа была запущенна или ситуация когда физическое соединение есть, но FreeSwitch по нему всё равно обнаружить нельзя, так как FreeSwitch в недоступном сегменте сети.

[alx]

Replying to dimag:

Иногда он не срабатывал,

Выяснена ли причина, по которой второй механизм иногда не срабатывал?

[dimag]

Да.
В первую очередь нужно было ориентироваться на наличие отклика от Freeswitch сервера по запросу status с временем ожидания 200 мс, если данный запрос успешно выполнялся, то считать что соединение существует, если нет, то считать что соединение разорванно и начать пытать восстановить соединение. Я вместо этого сперва ориентировался на наличие хотя 1 физического подключения в сети, особенно в главном потоке приложения.

[alx]

Replying to dimag:

Да.

Какова эта причина?

[dimag]

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

[alx]

Replying to dimag:

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

Верно ли я понял, что наличие физического соединения с сетью проверялось и в пользовательском потоке, и в потоке сообщений?

[dimag]

Верно ли я понял, что наличие физического соединения с сетью проверялось и в пользовательском потоке, и в потоке сообщений? Да.

[alx]

Верно ли я понял, что ранее (до коммита r480) ни пользовательский поток, ни поток сообщений на наличие связи с сервером не ориентировались?

[dimag]

Пользовательский поток нет.
Поток сообщений - частично.

[alx]

Replying to dimag:

Поток сообщений - частично.

"частично" - это как?

[dimag]

При наличие физического соединения проводилась проверка на наличие связи с сервером.

[alx]

Верно ли я понимаю, что в случае, о котором Александр пишет в описании тикета, произошло следующее:

• Пропало физическое соединение компьютера с сетью (ethernet).
• Так как физического соединения нет, проверка на наличие связи с сервером не производилась и, как следствие, не было индикации отсутствия связи с сервером.

???

[dimag]

Примерно так.

[alx]

Хорошо. Правильно ли я понял, что сейчас (начиная с r480) проверка на наличие связи с сервером выполняется независимо от наличия или отсутствия физического соединения?

[dimag]

Да.

[alx]

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

[dimag]

Давайте закроем.

[san]

Milestone deleted