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 или других "вредоностных" действий пользователей

Весьма интересно: Java Calendar Security Bug (и еще тут: http://blog.cr0.org/2009/05/write-once-own-everyone.html)

Лекарство для тех, у кого Java падает с диагностикой java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. на новых дистрибутивах:

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/java/jdk1.6.0_03/jre/lib/i386/xawt/libmawt.so

(или ждем когда зарелизят jdk 1.6.0 update 4 и обновления более старых jdk)

Ужоснах:

http://weblogs.java.net/blog/joconner/archive/2005/08/how_long_is_you.html

Via aefimov

Некоторые мысли в слух про архитектуру Swing

( инфа исключительно для программистов :-) )

Написал еще два полезных скрипта для обработки цифровых фоток на Linux'е:

1) Модификация предыдущего скрипта, ориентированная на экранное slideshow. Отличается тем, что на рамке (черного цвета) записыаеются параметры съемки из EXIF. Для вытаскивания EXIF используется ImageMagick, вывод которого окультуривается sed'ом и bc.

Скрипт тут: screenjpeg.sh

2) Для любителей XSLT преобразований, написан java-класс, раскрывающий EXIF информацию в XML. Изначально была идея написать это на shell/sed/bc, но разум в итоге восторжествовал (спасибо svv). Java-класс применяется совместно с Xalan'ом в цепочке XSLT преобразований. Для использования нужен EXIF-вытаскиватель http://www.drewnoakes.com/code/exif/

Исходники тут: ExifXsl.java. Пример применения тут: exif.xsl