Обработка сообщений OSB Proxy Service

В Weblogic OSB у нас есть прокси-служба, которая просто должна принимать сообщения из удаленной очереди Weblogic JMS и направлять их в другую удаленную очередь Weblogic JMS через бизнес-службу. По какой-то причине сообщения потребляются прокси-службой, но никогда не перенаправляются в бизнес-службу.

Текущее поведение:

Если эта функция включена, прокси-служба OSB удаляет все сообщения, помещенные в очередь URI удаленной конечной точки, но сообщения, похоже, не проходят в потоке сообщений самой прокси-службы. Когда прокси-служба включена, сообщения в удаленной очереди удаляются, но остаются в «ожидающем» состоянии. Когда служба прокси отключена, сообщения возвращаются в очередь.

Каковы возможные причины того, почему сообщения не обрабатываются в потоке сообщений прокси-службы? Все, что делает поток сообщений, - это направляет сообщения в бизнес-службу, которая затем отправляет сообщения в другую очередь URI удаленной конечной точки.

PS: Когда сообщение вводится в прокси-службу через тестовую консоль, потоки сообщений / маршруты в бизнес-службу проходят нормально без проблем, поэтому я предполагаю, что проблема должна быть где-то в начальной удаленной очереди / интерфейсе прокси-службы? Может быть, проблема с разрешениями или транзакцией? Но я не вижу никаких намеков на что-то не так в конфигурациях или журналах серверов ...

Заранее благодарим за любую помощь по этому поводу.


person Going Bananas    schedule 28.05.2013    source источник
comment
В консоли OSB перейдите к нужному прокси, щелкните вкладку «Рабочие параметры» и включите параметры трассировки. Может быть, это поможет вам вести журнал, чтобы определить, что происходит? Вы можете сделать это и для бизнес-услуг.   -  person Display Name is missing    schedule 28.05.2013
comment
@better_use_mkstemp, спасибо за предложение. Я действительно считаю, что у меня уже включена трассировка, но я не вижу ничего в журнале, когда прокси-служба включена и удаляет сообщение из удаленной очереди. Правильно ли я считаю, что журналы трассировки должны записываться в стандартный файл журнала сервера OSB? Или я ищу следы не в том месте?   -  person Going Bananas    schedule 29.05.2013
comment
Вы должны иметь возможность отслеживать журнал для управляемого сервера, прокси-сервер которого вы используете, и видеть такие сообщения, как: [OSB Tracing] Routing to /services/enterprise/DataService/v2.0.0/DataServiceBusiness с контекстом сообщения: а затем позже [OSB Tracing ] Следующие переменные изменены: или [OSB Tracing] был отправлен входящий ответ. Убедитесь, что это журнал управляемого сервера, а не другой. Что-то вроде ‹главная страница домена› / servers / ‹имя управляемого сервера› / logs   -  person Display Name is missing    schedule 29.05.2013
comment
Я просмотрел файлы журнала сервера OSB, и нет никаких признаков того, что какие-либо сообщения уровня трассировки регистрируются. Когда я включаю прокси-службу, я вижу журнал уровня INFO, который показывает: The Message-Driven EJB has connected/reconnected to the JMS destination: REMOTE_QUEUE_NAME и я вижу, что счетчик Messages Current удаленной очереди опускается до 0, а счетчик Messages Pending увеличивается до 1, но никаких следов чего-либо, проходящего через прокси-службу, не появляется в файлы журнала.   -  person Going Bananas    schedule 31.05.2013
comment
Вы решили проблему? У меня такая же проблема. Заранее спасибо.   -  person Bruno Gasparotto    schedule 10.02.2017
comment
@BrunoGasparotto, это было давно, но насколько я помню, нам пришлось прибегнуть к перезапуску самого сервера, чтобы снова получить сообщения обработки прокси-сервисом.   -  person Going Bananas    schedule 14.04.2017


Ответы (3)


Я столкнулся с той же проблемой и обнаружил, что это может быть проблема конфликта имен.

Если у вас есть повторяющиеся имена для ваших ресурсов, независимо от того, на каком сервере они находятся, WebLogic может вызвать неожиданное поведение. Итак, согласно документу Oracle Лучшие практики для начинающих и продвинутых JMS Пользователи, следует придерживаться следующих правил именования:

  • Доменные имена должны быть уникальными.
  • Имена серверов WebLogic должны быть уникальными, даже если они находятся в двух разных доменах.
  • Имена серверов JMS должны быть уникальными, даже если они находятся в двух разных доменах.

Чтобы проиллюстрировать сценарий выдачи вышеуказанных заявлений. У меня была следующая проблемная топология:

|   WebLogic    |   IP          |   Domain      |   Server      |
|   WebLogic 1  |   10.10.10.73 |   osb_domain  |   osb_server1 |
|   WebLogic 2  |   10.10.10.83 |   osb_domain  |   osb_server1 |
|   WebLogic 3  |   10.10.10.93 |   osb_domain  |   osb_server1 |

Обратите внимание на конфликт имен между доменами и серверами. Даже если бы у меня были разные имена для моих ресурсов JMS, этих конфликтов имен было достаточно, чтобы вызвать проблемы.

Затем я изменил свою топологию на следующую:

|   WebLogic    |   IP          |   Domain      |   Server      |
|   WebLogic 1  |   10.10.10.73 |   osb_domain1 |   osb_server1 |
|   WebLogic 2  |   10.10.10.83 |   osb_domain2 |   osb_server2 |
|   WebLogic 3  |   10.10.10.93 |   osb_domain3 |   osb_server3 |

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

person Bruno Gasparotto    schedule 11.04.2017
comment
Проблемы конфликта имен вполне могли быть проблемой для доменов Weblogic в исходной настройке вопроса. Я не могу точно сказать, что это была проблема сейчас, но ваш комментарий может помочь другим в будущем. - person Going Bananas; 14.04.2017

В своей службе прокси перейдите на вкладку «Параметры работы» и убедитесь, что у вас включено ведение журнала для отладки с включенной трассировкой. Для трассировки необходимо установить значение «Полный», а размер - 800.

С уважением, Сайед К.

person Syed Kaleem    schedule 08.10.2013

вы можете установить свойство «MAx Messages Per Session» в JMS Connection Factory: значение по умолчанию - 10, установите его в 1, чтобы только 1 JMS-сообщение доставлялось каждому потребителю за раз. По умолчанию до 10 сообщений доставляются одному и тому же потребителю, у которого есть только 1 поток, поэтому все 10 помечаются как ожидающие, а обрабатывается только 1.

person Pierluigi Vernetto    schedule 10.01.2014