Если вы используете открытую библиотеку Axis, попробуйте послать в приложение пустой JSON. Он вполне может повесить все напрочь.
И самое главное — вы ничего не можете с этим сделать на своей стороне! Это баг в сторонней библиотеке. Так что тут или ждать официального исправления, или менять библиотеку, что может быть очень сложно.
На момент написания этого поста баг еще не исправлен (версия 1.4). А даже если бы был — так ли просто обновиться? Казалось бы, делов на 5 минут, обновил библиотеку, и свободен.
Но... В системе редко используется одна сторонняя библиотека. Обычно их несколько, они завязаны одна на другую. Чтобы их обновить, надо обновлять все сразу. Надо проводить рефакторинг , потому что они теперь по другому работают. Надо выделять ресурсы разработчиков.
В общем, просто обновление версии библиотеки порой занимает целый релиз крутого разработчика. Так, например, когда мы переезжали на новую версию Lucene, мы потратили на задачу 56 часов, это 7 человеко-дней, неделя фулл-тайм разработчика плюс тестирование. Сама задача выглядит примерно так:
И это просто обновление библиотеки! А уж отказаться от одной библиотеки из-за бага в ней вообще страшно представить, сколько времени займет...
Так что вполне возможно, что вы какое-то время просто будете жить с багом. Знать о нем, но ничего не менять. В конце концов, «нечего глупые запросы слать».
Но в любом случае о наличии бага нужно хотя бы знать. Потому что если к вам придет пользователь и скажет: «У вас все зависло», вы должны понять почему. При том, что в логах пусто. Потому что это не ваше приложение зависает, все виснет на этапе преобразования JSON-а.
Казалось бы — пустой запрос! А вот он к чему может привести... То есть даже если вы не знаете, что в Axis есть такой баг, вы можете просто проверить пустой JSON, пустой SOAP-запрос. В конце концов, это отличный пример теста на ноль в разрезе JSON-запроса.
Не забывайте тестировать ноль!
См также:
Класс эквивалентности «Ноль-не ноль» — подробнее о тестировании нуля
Мнемоника БМВ для поиска граничных значений — тоже поможет найти подобные баги, рассказ про пустой JSON входит в эту статью, просто решила отдельно тоже вынести.
И самое главное — вы ничего не можете с этим сделать на своей стороне! Это баг в сторонней библиотеке. Так что тут или ждать официального исправления, или менять библиотеку, что может быть очень сложно.
Скажете, что «никто в здравом уме не будет слать пустой JSON»? Ха-ха-ха!
Мы о баге библиотечки именно так и узнали — тестовый стенд стал зависать. Причина неизвестна. Искали, искали... И вот нашли.
Зачем разработчики интеграции посылали такие сообщения — непонятно. Но пришлось просить их прекратить ¯\_(ツ)_/¯
На момент написания этого поста баг еще не исправлен (версия 1.4). А даже если бы был — так ли просто обновиться? Казалось бы, делов на 5 минут, обновил библиотеку, и свободен.
Но... В системе редко используется одна сторонняя библиотека. Обычно их несколько, они завязаны одна на другую. Чтобы их обновить, надо обновлять все сразу. Надо проводить рефакторинг , потому что они теперь по другому работают. Надо выделять ресурсы разработчиков.
В общем, просто обновление версии библиотеки порой занимает целый релиз крутого разработчика. Так, например, когда мы переезжали на новую версию Lucene, мы потратили на задачу 56 часов, это 7 человеко-дней, неделя фулл-тайм разработчика плюс тестирование. Сама задача выглядит примерно так:
Lucene. Перейти на использование PointValues вместо Long/IntegerField
В Lucene Migration 5 -> 6 доке есть пункт об отказе от Long (Integer/Double) Field в пользу PointValues.
При переходе на Lucene 6.3.1 я оставил старые поля (все классы были переименованы с добавлением Legacy-префикса), потому что перевод тянет на отдельную задачу.
Нужно отказаться от старых полей и заиспользовать Long (Integer/Double) Point классы, которые по тестам быстрее и меньше весят в индексе. Придется переписать достаточно много кода.
Обязательно! Переход должен быть с обратной совместимостью, чтобы поиск (по крайней мере ключевые функции) не отломался с обновлением версии. Он должен работать на старом индексе (до перестроения), а после перестроения (в удобное заказчику время) должны подхватиться новые поля.
И это просто обновление библиотеки! А уж отказаться от одной библиотеки из-за бага в ней вообще страшно представить, сколько времени займет...
Так что вполне возможно, что вы какое-то время просто будете жить с багом. Знать о нем, но ничего не менять. В конце концов, «нечего глупые запросы слать».
Но в любом случае о наличии бага нужно хотя бы знать. Потому что если к вам придет пользователь и скажет: «У вас все зависло», вы должны понять почему. При том, что в логах пусто. Потому что это не ваше приложение зависает, все виснет на этапе преобразования JSON-а.
Казалось бы — пустой запрос! А вот он к чему может привести... То есть даже если вы не знаете, что в Axis есть такой баг, вы можете просто проверить пустой JSON, пустой SOAP-запрос. В конце концов, это отличный пример теста на ноль в разрезе JSON-запроса.
Не забывайте тестировать ноль!
См также:
Класс эквивалентности «Ноль-не ноль» — подробнее о тестировании нуля
Мнемоника БМВ для поиска граничных значений — тоже поможет найти подобные баги, рассказ про пустой JSON входит в эту статью, просто решила отдельно тоже вынести.
Комментариев нет:
Отправить комментарий