Мы используем Tibco 5.11 BW и EMS 8.0.0.9 на отдельных виртуальных серверах Windows 2008 R2 6.1.
Периодически примерно один раз в 1-2 месяца случайный процесс tibco BW из случайного пакета tibco BW зависает при активности «JMS Queue Sender». У нас около 80 пакетов Tibco BW и пара сотен процессов в каждом пакете. У большинства процессов внутри действительно простая логика. Процессы используют транспорт Tibco JMS.
Когда возникла проблема, она не выдает никаких ошибок в tra.log или application.log. Я вижу только висящие потоки с текущей активностью «Отправитель очереди JMS» в администраторе Tibco. После того, как активность «JMS Queue Sender» начинает зависать, все процессы из пакета также начинают зависать, и в конечном итоге пакет вообще не отвечает. Перезапуск пакета устраняет проблему.
«Активность отправителя JMS» использует очередь TMP в «destinationQueue». Службы можно вызывать из java с помощью tibjms.jar-7.0.1.jar или из другой службы tibco BW с помощью «JMS Queue Requestor».
Вот наш типичный пример службы, которая зависает на «отправителе очереди JMS».
Аналогичная проблема описана на форуме tibco, но без решения https://community.tibco.com/questions/jms-queue-sender-hung-state.
зависание «Действия отправителя JMS», вероятно, связано с временной очередью, установленной в ReplayTo. В качестве обходного пути мы меняем временную очередь на статическую, что решает проблему.
Вопрос в том, что вызывает зависание "активности JMS Sender" в случае временной очереди в ReplayTo?
UPD: это может быть связано с
5.14.0: BW-17137 Действия получателя JMS и отправителя JMS, которые использовали один и тот же ресурс подключения, оказались в ситуации мертвой блокировки при повторном подключении к серверу EMS.
5.13.0: BW-16413 Получатель JMS и отправитель JMS, которые использовали один и тот же ресурс подключения, оказались в мертвой блокировке при повторном подключении к серверу EMS.
К сожалению, я вижу только заголовок проблемы в примечания к выпуску 5.14 BW. Я не нашел подробного описания проблемы публично
