Есть JDBC-receiver (Оракл), который асинхронно получает данные. Асинхронно. Без всякого EOIO.
Сегодня столкнулся с проблемой -- при оракловых дедлоках в процессе вставки вся шина (7.1ehp4) перестаёт отправлять JDBC-сообщения в сторону получателей, любых. Получается что внешний асинхронный получатель может задосить все обмены при некоторых условиях

Возвращусь к указанной теме... Очень серъёзная и неприятная проблема, в Backlog видная через затык в DispatchDisp. Есть несколько нот на тему добавление диспетчеру ресурсов, правда у меня не получилось добавить как написано тут -- нота 1136790 Blocking receiver channel may affect the whole adapter type

Параметр messaging.system.queueParallelism.maxReceivers не меняется

Возможные дополнительные способы решения проблемы: установка лишней джава-ноды или вынос особо критичных JDBC-получателей в нецентральные адаптерные движки.

Нужно проставить таймауты:

driver:oracle.jdbc.ReadTimeout в миллисекундах
driver:oracle.net.CONNECT_TIMEOUT в миллисекундах
sqlquerytimeout в миллисекундах
poolWaitingTime в миллисекундах

taskTimeout в секундах

Еще можешь попробовать поставить галочку - отключаться от БД после каждого сообщения

Раньше меня эта проблема тоже данимала

таймаут от дедлока не спасает

Пробовал? У меня однозначно это помогло!

Кстати а как быть с другой похожей болячкой -- при одновременном засовывании скажем ~30-50 синхронных запросов, вылезает HTML ERROR 503 Error: /MessagingSystem/receive/AFW/XI is temporary unavailable. Думаю тут что-то связано с лимитом диалоговых рабочих процессов, т.к. если на ошибку запроса повторять его и повторять то в SM50 [censored]. Пока выкручиваюсь искусственными случайными задержками перед запросом (скажем от 10 до 60 секунд случайно спать), но это уже явно отжимает диалоговый процесс.

Или снова вариант -- все такие запросы выполнять не в CAE а в другом AE?

Уважаемый chumpa,

если еще актуально. В вашем случае, судя по всему, увеличение записей в очереди DispatchDisp свидетельствует о проблемах на одном из адаптеров, вызванных проблемами на backend системах. Как вы правильно заметили нужно задать значение для параметра messaging.system.queueParallelism.maxReceivers. Но поменять его в NWA не получится. Это делается при помощи утилиты configTool (для SAP PI 7.1 EHP 1). У меня была аналогичная проблема, но с RFC адаптером, когда из-за проблем на любой backend системе подвисал весь Java стек на SAP PI системе.

С уважением, Александр

У меня похожая проблема...

Есть PI 7.0 и его клон с апгрейдом до 7.1. На обоих в AF настроено Send.maxConsumers=20, Recv.maxConsumers=20, Call.maxConsumers=20, Rqst.maxConsumers=20 для SOAP и RFC.
Есть синх.сценарий SOAP - PI - BAPI настроенный на обеих системах.
Есть java-софтина, которая шлет http-запросы или дергает SOAP. Реализована многопоточность, т.е. отправлять она умеет сразу кучу синхронных запросов.

1) На PI 7.0
а) Тестирую SOAP вызовы. 100 вызовов с интервалом 200 мс.
Мониторю AF и вижу, что заполняются рабочие процессы SOAP, заполняются процессы RFC и как только все процессы заняты (BAPI выполняется секунды 4-5) начинает заполняться очередь SOAP . По мере выполнения BAPI-шек очередь SOAP очищается и все процессы SOAP и RFC освобождаются. Все ответы успешно получены.

б) Тестирую тоже самое только в обход SOAP, шлю сразу в IE http-запрос. 100 запросов с интервалом 200 мс.
Мониторю AF и вижу, что заполняются рабочие процессы RFC и как только все процессы заняты начинает заполняться очередь RFC. По мере выполнения BAPI-шек очередь RFC очищается и все процессы RFC освобождаются. Все ответы успешно получены.

Т.е. все так, как и должно быть ...

2) На PI 7.1
а) Тестирую SOAP вызовы. 100 вызовов с интервалом 200 мс.
Мониторю AF и вижу, что заполняются рабочие процессы SOAP (максимум 15 из 20), заполняются процессы RFC (максимум 15 из 20) и совсем не заполняется очередь SOAP. По мере выполнения BAPI-шек все процессы SOAP и RFC освобождаются.
Примерно треть запросов успешно отрабатывает. Две трети возвращается с ответом:
Error: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: java.security.PrivilegedActionException: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Bad response: (503Service Unavailable

б) Тестирую тоже самое только в обход SOAP, шлю сразу в IE http-запрос. 100 запросов с интервалом 200 мс.
Мониторю AF и вижу, что заполняются рабочие процессы RFC (максимум 15 из 20) и совсем не заполняется очередь RFC. По мере выполнения BAPI-шек все процессы RFC освобождаются.
Примерно одна пятая-шестая часть запросов успешно отрабатывает. Большинство же возвращается с ответом: Error: Server returned HTTP response code: 500 for URL:
В payload-e пишет:

"503 Service Unavailable
Error: /MessagingSystem/receive/AFW/XI is temporary unavailable."

Получается AF вместо того, чтобы складывать запросы в очередь, просто футболит их с ошибкой 503. При этом мониторинг AF в PI71 жутко тормозит и долго обновляет страницу.
Насчет DispatchDisp - не видно, что как-нить заполняется.

Как все это победить - пока не нашли ...

Проблема "503 Service Unvaliable" решена. Дело было в ограничении на кол-во http-соединений. https://service.sap.com/sap/support/notes/1469844
По дефолту было 15, соответственно 15 из 20 процессов и были заняты. Увеличили пока до 50, но для данного сценария походу мало.
Из 100 запросов все равно около 6-7 возвращаются с ошибкой 503.
Теперь используются все 20 процессов.
И очередь копится в DispatchDisp. А почему не в SOAP и RFC очередях?..

про 15 соединений не знал но опробую нагрузку, посмотрю
А DispatchDisp в 7.1 это единая точка входа, поэтому в нём независимо от адаптера и копится (вернее для каждого адаптера "свой" dispatchdisp но показано одной строкой)

Приветствую.
Вот и мы дошли до такого же. Непонятно по чему перестала отправлять JDBC-сообщения в сторону любых получателей. Вот уже второй раз это случилось.

Как решать?

привет!
RWB -> Component monitoring -> Display -> Adapter Engine -> Engine status
Messaging overview
Смотри, что в DLNG по JDBC.

ничего не вижу. Отправил картинки почтой.

Если там все по нулям, тогда что показывается в аудите сообщения в AE ?