maxcom

Хочу поделиться одним довольно интересным deadlock'ом, на который я уже дважды наступил на linux.org.ru.

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

Скрипты, генерирующие страничку обычно где-то в начале получают Connection, потом в конце его отдают. В новый скриптах это делается в контроллерах, в старом бардаке - прямо в коде JSP (но там мы используем большие буфера чтобы предотвратить Slow Lori атаки на соединения БД). Код работы с БД довольно запутан и размазан по исходникам.

В первый раз deadlock выглядет так - редко, наверное пару раз в месяц сайт полностью умирал. Все запросы висели в ожидании соединения к БД, все активные соединения висели в idle, БД и система были совершенно не загружены. Классическая картина "утечки" соединений, однако код был многократно исследован на эту тему - вся работа с БД была обернута в try { ... } finally, в котором соединение закрывалось. Никаких статических буферов для соединений к БД у нас нет. Принудительный вызов сборки мусора ситуацию не лечил.

Второй раз deadlock проявлялся сильнее, поскольку ошибка была сделана в скрипте генерирующем главную страницу - сайт после deploy'я жил несколько минут, после чего лочился.

Собственно причина лока была успешно установлена еще в первый раз, предлагаю читателям самостоятельно догадаться о причине (в github не смотреть :-)

Единственное уточню:

1) Пулы соединений предоставляет сервер приложений (tomcat), они работают корректно
2) Действительно вся работа с БД обернута в try { .. } finally, все что получается из пула туда обратно возвращается по окончанию скрипта
3) Все учавствующие в дедлоке запросы к БД работают довольно быстро, "перенагрузки" системы, БД и ввода вывода нет. Однако скорость возникновения лока напрямую зависит от популярности страницы, на которой сделана ошибка
4) Deadlock возникал не в следствии каких-то DoS или других "вредоностных" действий пользователей

Прям просится на стенку: http://samoleg.livejournal.com/218531.html

Красота какая: http://metasploit.com/users/hdm/tools/debian-openssl/

http://habrahabr.ru/blog/ui_design_and_usability/37494.html

Еденица измерения качества кода: WTFs / minute

http://habrahabr.ru/blog/humour/35322.html

Кстати появился перевод книги "Agile Web Development with Rails", надо будет купить как появится в продаже...

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

http://piston.rubyforge.org/index.html

руками (или, скажем, в CVS) это бы стоило большого гемороя

Как известно, портирование изменений из одного branch в другой в CVS/Subversion задача не легкая. Linus Torvalds в своей лекции о преимуществах git называл это одним из основных недостатков CVS/Subversion.

Допустим что мы хотим ответвить development-ветку для разработки какой-то функциональности с целью потом портировать сделанные в ней изменения на головной branch. Если действовать по "классической технике", то при долгой разработке возникнет проблема того, что головной branch за время разработки уходит вперед. В момент портирования изменений мы получаем массу гемороя по слиянию изменений. К тому же в больших командах слиянием изменений должен заниматься основной maintainer, а не разработчик работавший в development-ветке.

Почитав внимательно 4-ю главу Subversion Book обнаружил что существует техника применения branch'ей лишенная этого недостатка. Техника заключается в регулярном портировании изменений из головной ветки в ветку разработки. При этом разработчик development-ветви во-первых видит все изменения из головы, а во-вторых сам ответственен за адаптацию его работы к головной ветке разработки. Эта техника требует четкого отслеживания того, какие изменения спортированы, а какие еще нет. В CVS это потребует использования тегов, в Subversion рекоментуют записывать в лог ревизии репозитория при слиянии.

Много интересных докладов в avi: http://www.rit2007.ru/org.html, где бы еще найти время их посмотреть. Жаль звук местами плохо записан.

Linus Torvalds про git, cvs и другие системы управления версиями: http://www.youtube.com/watch?v=4XpnKHJAok8 (via alex_tomas)

Интересный факт: http://www.lenta.ru/news/2007/06/06/iis/. Впрочем, такая ситуация вполне типична с софтверной практике, включая opensource. Причем для opensource наверное даже более характерна чем для проприетарных софтов.

Решил понемного выводить движек linux.org.ru из каменного века. Поставил Subversion и Trac.

Про subversion писать не буду, скажу что после CVS мне он очень нравится.

Trac более интересная игрушка. Интегрированный пакет состоящий из bugtracker'а, wiki и броузера SVN. Удобный и функциональный интерфейс, ставится легко (хотя и требует компиляции какого-то невходящего в дистрибутив Fedora питоновского модуля).