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

Я использую 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-перехватчики-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>

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

2 ответа

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

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

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

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

Другие вопросы по тегам