Компонент, управляемый сообщениями (EJB3) в WebSphere 7, транзакции XA, обработка ошибок

Я относительно новичок в EJB. Предыстория: у меня есть MDB, использующий поставщик сообщений по умолчанию WebSphere, получающий сообщения MapMessages, у которого есть java.sql.DataSource для выполнения некоторой работы, используя подготовленное заявление, транзакцию jdbc и т. Д. Я настроил MDB в ibm-ejb-bnd.xml и ejb-jar.xml с использованием адаптера JCA со спецификацией активации и именем назначения. Я добавил java.sql.DataSource в ejb-jar и ibm-ejb-jar-bind. Я также добавил DataSource в MessageListener с аннотацией @Resource.

2 сценария, с которыми я не могу понять (первый сценарий исправлен, см. Обновление) ...

MDB, управляемый контейнером: драйвер DataSource несовместим с XA, поэтому я включил «Поддержка последнего участника» в WebSphere. Тем не менее, когда тип транзакции MDB установлен на Контейнер, я получаю сообщение об ошибке при фиксации:

[11/28/11 10:56:10:988 MST] 0000002e RegisteredRes E   WTRN0063E: An illegal attempt to commit a one phase capable resource with existing two phase capable resources has occurred.

Может быть, это связано с тем, что после фиксации DataSource возвращается к MessageListener, который делает его последним участником? Я считаю, что поставщик сообщений по умолчанию в WAS 7 является XA-совместимым, хотя я не видел никакой документации, в которой это прямо говорилось бы.

Сообщение повторяется еще 4 раза сразу после первой ошибки (даже если должна быть 30-секундная задержка в соответствии с ActivationSpec в WebSphere). Каждый раз выдается одна и та же ошибка. Согласно MessageListener, он завершился без ошибок, поэтому эта ошибка является частью замечательной транзакции, управляемой невидимым контейнером. Я не думаю, что мне нужны глобальные транзакции XA, поскольку есть только один DataSource, кроме JMS, откат транзакции я обрабатывал программно. Также сообщение JMS, MDB является асинхронным, AUTO-ACKNOWLEDGE. Как только сообщение получено, его можно подтвердить.

Если я ввожу ошибку приложения и возникает исключение, я сразу вижу эту ошибку 5 раз (без задержки):

[11/28/11 10:16:18:857 MST] 0000002b LocalExceptio E   CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "onMessage" on bean...

Поэтому я переключился на ................

MDB, управляемый компонентом: фиксация работает без ошибки XA и происходит только один раз. Однако обработка ошибок по-прежнему работает не так, как я ожидал или хочу! В классе MessageListener перехваченные исключения генерируют исключение EJB, которое, как я думаю, должно привести к тому, что MDB будет иметь желаемое поведение: Причина исключения для меня не имеет значения, когда MDB генерирует перехваченное исключение, не должно MDB следует повторить в соответствии со свойствами в WebSphereActivationSpec? Вместо этого сообщение отправляется в MessageListener 5 раз, сразу же вызывая ту же ошибку, что и MDB, управляемый контейнером: «EJB вызвал неожиданное (необъявленное) исключение ...»

Если я выброшу исключение RuntimeException, сообщение «Неожиданное (необъявленное) исключение» не появится, но сообщение будет повторяться сразу 4 раза вместо ожидания задержки повтора.

Спасибо за чтение, мы очень благодарны за любую помощь или понимание!

ОБНОВЛЕНИЕ: я решил проблемы совместимости с XA, переключив источник данных на XA-совместимый. В консоли администратора WAS: Ресурсы-> Поставщики JDBC-> DB2 Universal JDBC Driver Provider-> Измените имя класса реализации на: com.ibm.db2.jcc.DB2XADataSource

У меня все еще та же проблема, когда сообщение не удается. Повторная попытка выполняется немедленно, а не в соответствии со спецификацией ActivationSpec в WAS.


person Morgan Dowell    schedule 28.11.2011    source источник


Ответы (2)


Я считаю, что интервал повтора в спецификации активации относится к закрытым соединениям, а не к ошибочным сообщениям.

Вы должны определить интервал, который вы хотите в пункте назначения SIB.

Автобусы> АВТОБУС> Направления> НАЗНАЧЕНИЕ

Посмотрите на пункт назначения исключения

Максимальное количество неудачных доставок на одно сообщение - это сколько раз сообщение будет отправлено до тех пор, пока оно не будет объявлено неудачным (по умолчанию 5, поэтому вы получаете еще 4 раза)

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

person Aviram Segal    schedule 10.01.2012
comment
Спасибо Спасибо. Я задавал этот вопрос на нескольких форумах, но никто не ответил. - person Morgan Dowell; 22.03.2012
comment
Не уверен, следует ли мне задать новый вопрос и направить вам письмо, но можно ли установить задержку между доставками до того, как сообщение будет объявлено неудавшимся? - person Morgan Dowell; 22.03.2012
comment
Если я помню, вы можете либо установить его на сбой, либо начать повторную попытку через определенный интервал, я не думаю, что вы можете установить интервал для первых X раз, прежде чем он потерпит неудачу. но я могу ошибаться в этом. - person Aviram Segal; 29.03.2012

Я не знаю, нужен ли он вам, но вы должны проверить настраиваемое свойство: sib.processor.blockedRetryTimeout, определенное для механизма обмена сообщениями.

Это то, что вы ищете, пока сообщение ожидает повторной доставки, оно находится в состоянии РАЗБЛОКИРОВАНО и, следовательно, может быть отброшено.

person genialmaniac    schedule 23.03.2012