pgAdmin III и Avast!

С определенного момента антивирус Avast! стал мешать запуску pgAdmin III (1.20.0). Процесс pgAdmin вроде бы появляется в диспетчере, но самого приложения не видно. Выход - добавить папку C:\Program Files\PostgreSQL\9.4\* в исключения экрана файловой системы Avast (Настройки -> Активная защита -> Экран файловой системы -> Настройки -> Исключения).

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-дамп всех функций готов к накату на другие БД. 

Спасибо http://stackoverflow.com/questions/13758003/how-to-take-backup-of-functions-only-in-postgres.

Ожидание заданного в миллисекундах интервала в 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 мс.

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"/>

Birt: определение числа строк в DataSet'е

Задача

Необходимо определить число строк в некотором DataSet'е, чтобы затем использовать это значение в скрипте.

Решение

Как вариант - создаем JS-переменную, равную 0, и в обработчике onFetch нужно датасэта выполняем ее инкремент.

Определение внешнего IP-адреса из консоли

curl https://ipinfo.io/ip

WSO2 ESB: как отключить динамическую регулировку числа потоков, слушающих JMS-очередь

Есть прокси-сервис, слушающий JMS-очередь. Работа в несколько потоков для него настроена параметрами transport.jms.ConcurrentConsumers и transport.jms.MaxConcurrentConsumers (см. http://axis.apache.org/axis2/java/transports/jms.html). Однако, каким бы ни было значение transport.jms.ConcurrentConsumers, в "состоянии покоя", т.е. когда в очереди-источнике сообщений нет, на очереди висит только 1 получатель. По мере появления сообщений в очереди число получателей растет вплоть до указанного в transport.jms.MaxConcurrentConsumers ограничения. Затем, после опустошения очереди, получатели начинают отключаться, пока снова не остается только 1 получатель.

Объясняется такое поведение вот чем. Изначально шина создает для очереди столько слушателей, сколько указано в параметре transport.jms.ConcurrentConsumers. Каждый получатель начинает цикл опроса очереди, при этом на каждой итерации он ожидает получения сообщения в течение некоторого промежутка времени, заданного параметром transport.jms.ReceiveTimeout (по-умолчанию 1000мс). После определенного числа "холостых" итераций, в результате которых таймаут вышел, а сообщение так и не было получено, слушатель самозавершается. Число итерацией определяется параметром transport.jms.IdleTaskLimit и по-умолчанию равно 10. В итоге, через примерно 10 секунд завершаются все слушатели кроме одного "дежурного", который не завершается ни при каких обстоятельствах.

Данная ситуация не во всех случаях может устраивать, иногда нужно, чтобы очередь всегда слушало фиксированное число слушателей (например, при использовании группировки сообщеий). Тут варианта 2:

1. Устанавливаем очень большое значение параметра transport.jms.IdleTaskLimit (т.к. бесконечное значение установить нельзя, можно поставить, к примеру, 2147483647)
2. Устанавливаем бесконечный таймаут ожидания получателем сообщения путем установки параметра transport.jms.ReceiveTimeout в -1