Сообщения, находящиеся в очереди подписчика

Я использую jboss-5.1 для развертывания компонента, управляемого сообщениями, который используется для подписки на сообщения из сторонней очереди.

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

Насколько я проанализировал, я думаю, что maxsize и maxsession могли повлиять на это, поскольку обоим по 15 лет. Но я не понимаю, была ли какая-то реальная проблема, как она была решена простым перезапуском.

Журналы были в режиме ошибки. Я не получил полную трассировку стека.

Это фрагмент журнала ошибок.

[2012-10-30 17:01:00,228] [MQQueueAgent (GQH1_PLANNING_MDM_001)]
[ERROR] STDERR: 2012.10.30 17:01:00 MQJMS1023E rollback failed

[2012-10-30 17:01:00,228] [exceptionDelivery0] [WARN ]
org.jboss.resource.adapter.jms.inflow.JmsActivation: Failure in jms activation 
org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@85d0d(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@b21aae
destination=remotewsmq/NOTIFICATION_PLANNING_MDM_001.SUBQ
destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=RemoteWSMQJMSProvider
 user=null maxMessages=1 minSession=1 maxSession=5 keepAlive=60000 useDLQ=false)

GQH1_PLANNING_MDM_001: имя очереди, используемой для подписки.

Файлы, которые я использую для настройки свойств MDB, следующие.

1.ejb3-interceptors-aop.xml

  <domain name="Message Driven Bean" extends="Intercepted Bean" inheritBindings="true">
      <bind pointcut="execution(public * *->*(..))">
         <interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptorFactory"/>
      </bind>

      <!-- TODO: Authorization? -->

      <bind pointcut="execution(public * *->*(..))">
         <interceptor-ref name="org.jboss.ejb3.tx.CMTTxInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/>
         <interceptor-ref name="org.jboss.ejb3.tx.BMTTxInterceptorFactory"/>
         <interceptor-ref name="org.jboss.ejb3.AllowedOperationsInterceptor"/>
         <interceptor-ref name="org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor"/>
         <!-- interceptor-ref name="org.jboss.ejb3.interceptor.EJB3InterceptorsFactory"/ -->
         <stack-ref name="EJBInterceptors"/>
      </bind>

      <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
         @org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
      </annotation>
   </domain>

2.standardjboss.xml

<invoker-proxy-binding>
      <name>message-driven-bean</name>
      <invoker-mbean>default</invoker-mbean>
      <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
      <proxy-factory-config>
        <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
        <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
        <CreateJBossMQDestination>false</CreateJBossMQDestination>

        <!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed -->

        <MinimumSize>1</MinimumSize>
        <MaximumSize>15</MaximumSize>
        <KeepAliveMillis>30000</KeepAliveMillis>
        <MaxMessages>1</MaxMessages>

        <MDBConfig>
          <ReconnectIntervalSec>10</ReconnectIntervalSec>
          <DLQConfig>
            <DestinationQueue>queue/DLQ</DestinationQueue>
            <MaxTimesRedelivered>10</MaxTimesRedelivered>
            <TimeToLive>0</TimeToLive>
          </DLQConfig>
        </MDBConfig>

      </proxy-factory-config>
    </invoker-proxy-binding>

   <activation-config-property>
        <activation-config-property-name>maxSession</activation-config-property-name>
        <activation-config-property-value>15</activation-config-property-value>
   </activation-config-property>

3.jms-ds.xml

<?xml version="1.0" encoding="UTF-8"?>

<connection-factories>

  <!-- ==================================================================== -->
  <!-- JMS Stuff                                                            -->
  <!-- ==================================================================== -->

   <!--
       The JMS provider loader. Currently pointing to a non-clustered ConnectionFactory. Need to
       be replaced with a clustered non-load-balanced ConnectionFactory when it becomes available.
       See http://jira.jboss.org/jira/browse/JBMESSAGING-843. 
   -->
   <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
          name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider">
      <attribute name="ProviderName">DefaultJMSProvider</attribute>
      <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
      <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
      <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
      <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
   </mbean>

   <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
   <tx-connection-factory>
      <jndi-name>JmsXA</jndi-name>
      <xa-transaction/>
      <rar-name>jms-ra.rar</rar-name>
      <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
      <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
      <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
      <max-pool-size>20</max-pool-size>
      <security-domain-and-application>JmsXARealm</security-domain-and-application>
      <depends>jboss.messaging:service=ServerPeer</depends>
   </tx-connection-factory>

</connection-factories>

Пожалуйста помоги.


person dev    schedule 06.11.2012    source источник


Ответы (2)


Если слушатель не пытался переподключиться, то причиной сбоя могли быть ожидающие сообщения.

person user1807058    schedule 07.11.2012

Согласно ошибке, вызов транзакции ROLLBACK завершился неудачно. После сбоя администратор очередей, вероятно, задержал эти сообщения в незавершенной единице работы. Перезапуск сервера привел бы к закрытию соединения, после чего администратор очередей отменил бы транзакцию от имени приложения. При перезапуске приложение создаст новый UOW и получит сообщения.

Просмотрите журналы ошибок администратора очередей WebSphere MQ и глобальные журналы ошибок, чтобы определить, была ли ошибка вызвана нехваткой ресурсов. Может потребоваться увеличить размер журналов транзакций администратора очередей или настроить такие параметры транзакций, как MAXUOW.

Вам также может потребоваться обновить версию клиента MQ или версию диспетчера очередей. Согласно этой технической заметке, классы WebSphere MQ JMS были обновлены с 6.0.2.3 для исправления ошибки, приводившей к ошибкам MQJMS1023E. Если вам необходимо обновить версию клиента, ее можно бесплатно загрузить как SupportPac MQC75. Новый клиент может работать с любым администратором очередей предыдущего уровня. После обновления приложение получает исправления ошибок и улучшения производительности нового клиентского кода, а также предоставляет функции API, соответствующие версии Queue Manager, к которой оно подключается. Какая версия JMS-клиента WebSphere MQ установлена ​​в настоящее время? Какая версия администратора очередей WebSphere MQ установлена ​​в настоящее время?

person T.Rob    schedule 07.11.2012
comment
Применимо ли это MAXUOW к jboss? Если да, то знаете ли вы способ его установки. В нашем случае, как только мы получаем сообщение, мы просто фиксируем его. Поэтому, если возникает какая-то проблема, мы просто не обрабатываем ее. Таким образом, не может быть и речи о сбое транзакции. - person dev; 07.11.2012
comment
В моем понимании причина может быть в этом. - person dev; 07.11.2012
comment
Когда пакет сообщений JMS доставляется в MDB в количестве предварительной выборки, каждому присваивается экземпляр из этого пула, и они доставляются в этот экземпляр с помощью функции onMessage. Если предварительная выборка сообщения превышает maxSize этого пула, сообщения ожидают экземпляра MDB. Если время от доставки сообщения до вызова onMessage превышает время ожидания пула для любого сообщения, будет выдано исключение EJBException. При большой предварительной выборке и длительном среднем времени onMessage сообщения ближе к концу очереди начнут давать сбой. Но опять же я не понимаю, какой перезапуск сервера мог измениться? - person dev; 07.11.2012
comment
Возможно, вы думаете о MAXUMSGS, я знаю, что я был, когда я неправильно написал MAXUOW на сервере списка и ТАК несколько раз. MAXUMSGS — это атрибут QMgr. Вы определили версии QMgr и клиента? Что говорят журналы ошибок на стороне QMgr? - person T.Rob; 07.11.2012