Ура - ошибка платформы № 10167670 исправлена - настало время описать историю поиска этого бага.
В сентябре расследовал запутанный инцидент: после обновления платформы периодически обмен заказами с сайтом не работал (сам обмен осуществляется через web-сервис). Попытка воспроизвести баг локально успехом не увенчалась - развернул базу, настроил Apache2 - запросы через SoapUI отрабатывали стабильно хорошо (но эти же запросы на "боевом" сервисе периодически отрабатывали некорректно).
Сам сервис написан таким образом, что на один и тот же запрос может быть разный ответ (упрощенно: если заказ не создан - создание заказа в базе 1С и ответ "ок", создан - обновление некоторых данных из запроса и ответ "обновлен"). Пришлось включить дебаг на боевом сервере: после нескольких запросов заметил странную особенность - на один запрос обработчик иногда вызывался дважды (стало понятно, почему для нового заказа возвращался ответ "обновлен"). Попробовал опубликовать стандартный для новых версий конфигураций сервис, который возвращает версию БСП (AddressSystem.Ping) - примерно на один из 20 запросов он отрабатывал дважды. Попросил администратора сервера изучить логи web-сервера на наличие дубля запросов (чтобы исключить вариант неправильно настройки сетевого оборудования и соответствующего софта). Дублей не нашли - значит запрос приходит один, а обрабатывается дважды.
После первичной обработки на стороне web-сервера запрос передается "Модулю расширения веб-сервера" - ещё одно место, где запрос мог "дублироваться". Повторная публикация и рестарт web-сервера проблему не исправили, при беглом осмотре vrd-файла ничего подозрительного не заметил. Здесь стоить упомянуть один момент - боевой сервер весьма загружен. При последующем детальном изучении vrd-файла значения атрибутов тэга pool смутило - очень "оптимистичные" для такого железа. Увеличение значений по времени ожидания, таймауту и периоду проверки в 10 раз решило проблему "дублирующегося" запроса. Решил проверить резервную копию vrd-файла - там настройки были в порядке. Ещё одна попытка публикации (с использованием резервной копии vrd-файла) смутила тем, что не все значения атрибутов тега pool загрузились. Попробовал воспроизвести проблему на IIS - поведение аналогичное - значит это баг платформы. Поиск на bugboard.v8.1c.ru ничего не дал - но это не всегда означает отсутствие бага в багтрекере 1С (список ошибок весьма большой - просмотреть все займет много времени, искать по описанию - та ещё лотерея :) ). Попробовал воспроизвести на тестируемой версии платформы - баг повторяется.
Оставалось описать баг в фирму 1С - как оказалось - это отдельный квест :)
P.S.: на адрес testplatform@1c.ru нужно отправлять те баги, которые воспроизводятся только в тестовых версиях платформы (по текущим версия нужно писать на v8@1c.ru). Без регистрационного номера письма v8@1c.ru даже не рассматривает, без подписки ИТС они дают стандартную отписку "Вопросы, касающиеся ошибок программы рассматриваются, но ответ не отправляется" (по факту баг в багтрекер не попадает). В итоге, чтобы помочь фирме 1С улучшить свой продукт, нужно иметь подписку ИТС.
В сентябре расследовал запутанный инцидент: после обновления платформы периодически обмен заказами с сайтом не работал (сам обмен осуществляется через web-сервис). Попытка воспроизвести баг локально успехом не увенчалась - развернул базу, настроил Apache2 - запросы через SoapUI отрабатывали стабильно хорошо (но эти же запросы на "боевом" сервисе периодически отрабатывали некорректно).
Сам сервис написан таким образом, что на один и тот же запрос может быть разный ответ (упрощенно: если заказ не создан - создание заказа в базе 1С и ответ "ок", создан - обновление некоторых данных из запроса и ответ "обновлен"). Пришлось включить дебаг на боевом сервере: после нескольких запросов заметил странную особенность - на один запрос обработчик иногда вызывался дважды (стало понятно, почему для нового заказа возвращался ответ "обновлен"). Попробовал опубликовать стандартный для новых версий конфигураций сервис, который возвращает версию БСП (AddressSystem.Ping) - примерно на один из 20 запросов он отрабатывал дважды. Попросил администратора сервера изучить логи web-сервера на наличие дубля запросов (чтобы исключить вариант неправильно настройки сетевого оборудования и соответствующего софта). Дублей не нашли - значит запрос приходит один, а обрабатывается дважды.
После первичной обработки на стороне web-сервера запрос передается "Модулю расширения веб-сервера" - ещё одно место, где запрос мог "дублироваться". Повторная публикация и рестарт web-сервера проблему не исправили, при беглом осмотре vrd-файла ничего подозрительного не заметил. Здесь стоить упомянуть один момент - боевой сервер весьма загружен. При последующем детальном изучении vrd-файла значения атрибутов тэга pool смутило - очень "оптимистичные" для такого железа. Увеличение значений по времени ожидания, таймауту и периоду проверки в 10 раз решило проблему "дублирующегося" запроса. Решил проверить резервную копию vrd-файла - там настройки были в порядке. Ещё одна попытка публикации (с использованием резервной копии vrd-файла) смутила тем, что не все значения атрибутов тега pool загрузились. Попробовал воспроизвести проблему на IIS - поведение аналогичное - значит это баг платформы. Поиск на bugboard.v8.1c.ru ничего не дал - но это не всегда означает отсутствие бага в багтрекере 1С (список ошибок весьма большой - просмотреть все займет много времени, искать по описанию - та ещё лотерея :) ). Попробовал воспроизвести на тестируемой версии платформы - баг повторяется.
Оставалось описать баг в фирму 1С - как оказалось - это отдельный квест :)
P.S.: на адрес testplatform@1c.ru нужно отправлять те баги, которые воспроизводятся только в тестовых версиях платформы (по текущим версия нужно писать на v8@1c.ru). Без регистрационного номера письма v8@1c.ru даже не рассматривает, без подписки ИТС они дают стандартную отписку "Вопросы, касающиеся ошибок программы рассматриваются, но ответ не отправляется" (по факту баг в багтрекер не попадает). В итоге, чтобы помочь фирме 1С улучшить свой продукт, нужно иметь подписку ИТС.
Комментариев нет:
Отправить комментарий