Случай из практики
А вот я на фронте былОх-ты, боже мой...
Возможно, многие в отличие от меня знают про такую пакость, но я надеюсь, что найдется хотя бы пара-тройка человек, которым я сэкономлю время, деньги и нервы...
Анамнез:
У одного из наших клиентов учет построен на связке УНФ+БП 2.0. Обе базы – в клиент-серверном варианте. Обмен – по расписанию, по типовому (немного измененному) плану обмена через общий каталог.
Несколько месяцев назад возникла странная проблема: часть объектов (самых разных, и документов, и элементов справочников), созданных в УНФ, с непонятной периодичностью перестали переезжать в БП. После принудительной регистрации и ручного запуска обмена объекты спокойно передавались. На некоторое время, иногда короткое, иногда не очень, ситуация приходила в норму, а потом все повторялось без каких бы то ни было видимых причин (Зараза!!!). Поскольку крики погибающих бухов: «Обмен опять не работает!» - происходили в самые горячие отчетные дни, долго разбираться времени не было, обмен проталкивали вручную. И вот…
Лечение:
В общем, с ног сбились, грешили на правила регистрации, на правила обмена, на потерю файлов на сервере, на алгоритм в УНФ, который определяет помечать ли объект как измененный или нет в зависимости от того, какие реквизиты изменились. И еще бог знает на что! Оказалось…
Некоторое время назад на боевом сервере создали тестовую базу УНФ, загрузили туда копию рабочей базы, чего-то там проверили на ней и забыли про нее напрочь. Естественно, в тестовой базе остались то же самое расписание и тот же самый каталог обмена, что и рабочей базе. И фоновое задание, выполняющее обмен, продолжало запускаться, как ни в чем не бывало.
Теперь – самое интересное. Сеансы обмена запускались в обеих базах УНФ параллельно в одно и то же время, причем, кто из них оказывался первым, определялось каким-то квази-случайным способом. При этом, в тестовой базе, естественно, никаких измененных объектов не возникало, потому что в ней никто уже не работал! Если фоновое задание в тестовой базе опережало аналогичное задание в рабочей базе, то все шло нормально – файл, созданный в рабочей базе, затирал файл из тестовой базы, и никто ничего не замечал. Если же задания запускались в обратном порядке, то ПУСТОЙ файл из тестовой базы затирал файл с выгруженными объектами из рабочей базы и никакого обмена не происходило.
Дальше – больше. Поначалу сообщения в рабочей и тестовой базах создавались с одними и теми же исходящими номерами сообщений. Потом, по мере ручных запусков процедур обмена в рабочей базе, номера исходящих сообщений в тестовой базе стали отставать. В результате, если фоновое задание в тестовой базе запускалось после фонового задания в рабочей базе, в каталоге обмена оставался файл с номером сообщения, которое уже принималось в БП. БП, естественно, его отфутболивала, и никакого обмена опять-таки не происходило…
Обнаружилось это таким образом. В обработку, выполняющую обмен, я добавил копирование создаваемого файла обмена в файл с уникальным именем, чтобы выследить-таки мерзавца. После очередного «сбоя» обмена, анализируя каталог с этими копиями, я обнаружил, что за один и тот же сеанс обмена имеются два файла с разными номерами сообщений, один из которых оказался пустым! Анализ журнала регистрации показал, что в момент времени, указанный в «пустом» файле, НИКАКИХ ФОНОВЫХ ЗАДАНИЙ в рабочей базе НЕ ВЫПОЛНЯЛОСЬ! Опаньки, приплыли…
К счастью, я достаточно быстро догадался, что это не нечистая сила, и не происки врагов «из-за бугра», а просто есть еще какая-то база, которая пишет файлы обмена в тот же самый каталог. Вот! Базу тут же нашли и со злорадным удовлетворением грохнули.
Мораль:
1.Нечистой силы не бывает
2.Посуду надо мыть за собой сразу, не дожидаясь пока тараканы заведутся.
С уважением ко всем дочитавшим до конца, Дядюшка О.
Вступайте в нашу телеграмм-группу Инфостарт