barbitoff programmer`s blog

Здесь я публикую заметки из программерской жизни: грабли, на которые мне случилось наступить, проблемы, для которых было найдено элегантное (или не очень) решение, а также все, с чем мне пришлось столкнуться и чем хотелось бы поделиться =)
PS Если хотите меня поблагодарить - на странице есть 3 места, чтобы это сделать =)

среда, 15 февраля 2017 г.

PostgreSQL: Дамп функций из определённой схемы БД

Определения функций из определенной схемы БД PostgreSQL выгружаются следующим запросом:
SELECT pg_get_functiondef(f.oid)
FROM pg_catalog.pg_proc f
INNER JOIN pg_catalog.pg_namespace n ON (f.pronamespace = n.oid)
WHERE n.nspname = 'myschema';
Осталось только записать вывод этого запроса в файл с разделителем строк ";" - и вуаля, sql-дамп всех функций готов к накату на другие БД. 

вторник, 14 февраля 2017 г.

Ожидание заданного в миллисекундах интервала в bat-файле

Вариантов реализации ожидания заданного в миллисекундах интервала в bat-файле много, один из них:
ping -n 1 -w <интервал в мс> 10.10.254.254 >nul
Здесь важно, что 10.10.254.254 - гарантированно несуществующий ip.
А если нужно ждать рандомное число мс в заданном диапазоне:
set /a randms=500+1000*%random%/32768
ping -n 1 -w %randms% 10.10.254.254 >nul 
Здесь делается рандомная задержка от 500 до 1000 мс.

вторник, 7 февраля 2017 г.

WSO2 ESB, ActiveMQ и игнорирование AMQ_SCHEDULED_DELAY

Проблема

Есть прокси-сервис на WSO2 ESB 4.9.0, слушающий некоторую очередь на ActiviMQ 5.13.1. В некоторых ветках своей логики прокси-сервис помещает полученное из очереди сообщение обратно очередь, устанавливая при этом AMQ_SCHEDULED_DELAY для обеспечения задержки перед повторной обработкой сообщения. Проблема заключается в том, что ActiveMQ принимает во внимание установленный AMQ_SCHEDULED_DELAY только при первом цикле такого повторного размещения. В последующих циклах AMQ_SCHEDULED_DELAY игнорируется, и сообщение поступает в обработку моментально.

Решение

Можно лишь предполагать, чем вызвано такое поведение (или лезть в исходники ActiveMQ, чего делать не очень хочется). Вероятно, т.к. сообщение повторно размещается с тем же Message ID, ActiveMQ как-то запоминает, что таймер AMQ_SCHEDULED_DELAY для этого Message ID уже устанавливался, и не устанавливает его повторно. В качестве workaround'а подходит очистка транспортных заголовков перед повторным размещением сообщения в очередь:
<property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/>