Квантовомеханические эффекты в макромире

[4px]

Не знаю, чем еще объяснить сегодняшние события.

Дано:Задача, запускающаяся по расписанию два раза в день. Иногда она не хотела выполнять свои обязанности, проблема устранялась повторным запуском вручную. В последние недели она вообще перестала работать. Приходилось каждое утро по несколько раз стартовать ее ручками и ожидать уведомления об

Comments

[mynine]

Судя по поведению (случайному) программы и "исправлению" после некоего внешнего вмешательства, мне видятся несколько возможных причин:
1 После оборачивания и логгирования вполне могли измениться тайминги работы с сетью.
2 Внешняя программа могла добавить точку синхронизации между потоками
3 Изменились рабочие адреса в памяти программы и замаскировалась какая-то бага с неинициализорованными переменными

[4px]

1. чисто теоретически, запуск tcpdump не должен ничего менять, ибо работает в отдельном процессе, якобы не влияющем на исходный. с другой стороны, какие-то низкоуровневые тайминги могли поменяться, да. логи были включены намного раньше, при них ошибка сохранялась, но логи не показывают что именно присылает сервер в ответ, т.е. есть текст error fetching http headers, а самих headers не видно. tcpdump один раз дал отловить ошибку (начало headers было вполне адекватное), но пакеты были не полностью записаны из-за неправильных настроек.
2. ну то же самое, что и в первом пункте. непонятно.
3. память по идее при каждом запуске разная, в доступных нам переменных точно нет ничего неинициализированного. да и все это раньше работало несколько лет почти без изменений.

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

[mynine]

Тут я перечислил те проблемы, с которыми лично сталкивался, но есть еще куча вариантов которые мне еще не попадались :)
Никогда не пользовал tcpdump, только WireShark - тот точно работает отдельно и перехватывает любую сетевую активность.
Да проблема может быть с той стороны, но тогда действительно могли измениться тайминги - чуть больше задержки с этой стороны и та отвечает по-другому.

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

[4px]

tcpdump та же фигня что и WireShark. На той стороне могла изменяться общая нагрузка на железо, соответственно IIS - черная коробочка - ведет себя уже так как ему заблагорассудится.

Странный эффект с лисой. Жабоскрипты там не примешивались никак? Надстройки? Просто это конкретный баг с его стороны, двойной запрос - это же АдЪ и Израэль.

[mynine]

Я перепробовал все варианты что только придумать мог: изначально был элементарный скрипт, формировавший запрос по клику, добавил таймаут, если только что отправлял - пофигу. Выкинул скрипт и сформировал линк при генерации - тоже пофигу. Потом стал передавать данные в куках - тоже сбоит. Чего-то я еще пробовал, менял версии ФФ, перетыкал сетевые провода из свитча напрямую, сетевуху сменил ненадолго. так ничего и не вышло. Опера, хром, ИЭ, работают без проблем - фф формирует двойной запрос :( Вот только уникальным номером в куках удается отбрасывать левые запросы.
А ФФ лучше всех отчеты для печати генерит, и без него никак :(

[4px]

т.е. если формировать запрос жабоскриптом, то все равно уходит по одному вызову функции два запроса?

[mynine]

Да. Я же говорю : ставил защиту с таймером на повторный вход в функцию - если два раза быстро кликнуть, то защита отрабатывает. Но запросы все равно время от времени уходят парами. Хоть скриптом, хоть просто переход по линку.

[4px]

Опасный браузер.
А версия какая?

[mynine]

Но это было только на некоторых компах, зато стабильно. Версий я несколько тогда пробовал, но достаточно старые, еще до того как они мажорные начали раз в месяц менять :)))) С тех пор как сделал защиту, больше не экспериментировал.

[4px]

у меня тут опять квантовые эффекты наблюдения проявились, перечитываю каменты.
огнелис в те времена мог как раз начать применять долбаный запрос для безопасности кроссдоменных запросов: ты делаешь из жабоскрипта аяксом гет или пост, но браузер за тебя делает сначала OPTION-запрос, на который сервер должен ответить что он допускает геты и посты от твоего домена. Щас все браузеры так делают.

[4px]

IIS на удаленной стороне, принимающий SOAP-запросы, закрывает соединение со статусом 64, не отвечает вообще ничего.

[mynine]

это вот у вас не из этой серии?

http://www.it-notebook.org/iis/article/scwin32status_64_scstatus_200.htm

[4px]

да, это оно.

Нашли причину разрыва соединения. На запрашиваеющей стороне в библиотеку SOAP жестко вшит таймаут соединения в 60 с. Это не регулируется никакими настройками, доступными программисту. Решение - унаследовать объект и перегрузить в нем метод генерации вызова, подставив там свои таймауты по желанию.

Но, естественно это не решает вопрос, почему когда мы наблюдаем за системой, она перестает давать сбои.

[mynine]

Хм, ваще это очень большой таймаут, если на ожидание ответа. Или это таймаут на какие-то необязательные действия?

Все же похоже на п1 из моего первого коммента.

[4px]

Ну таймаут как таймаут, там же подразумевается вызов функций на удаленном сервере, мало ли что. Хотя для наших серверов слишком большой, у нас уже через 20 секунд отдается "504 Досвидания". А вот для фоновой задачи по расписанию он наоборот маловат, там слишком большие массивы данных обрабатываются. В норме это занимает как раз секунд 20, но видимо выросли нагрузки, иногда выходит за 60 секунд и все умирает.

[ext_695368]

Что это за SOAP библиотека такая?