Использование Artemis, JBoss EAP 7.1 и очереди последних значений

Question

Мы используем JMS-очереди поверх JBoss EAP 7.1 и Spring 4.3.10.

Мы хотим задать определенную c очередь как «last-value-queue», как подробно здесь .

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

Если мы сохраняем конфигурацию потребителя и используем Thread.sleep() для имитации длительного процесса, чтобы не сразу потреблять сообщения, отличные от первого, то сообщения с тем же значением _AMQ_LVQ_NAME не отображаются. не отбрасывается и накапливается в очереди.

У вас есть какие-либо подсказки?

Наша конфигурация JBoss в standalone.xml:

<?xml version="1.0" encoding="UTF-8"?>
<subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
   <server name="default">
    ...
      <security-setting name="#">
         <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true" />
      </security-setting>
      ...
      <address-setting name="jms.queue.NgedeRequestQueue" last-value-queue="true" address-full-policy="BLOCK" />
      <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000" />
      <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue" />
      <jms-queue name="DLQ" entries="java:/jms/queue/DLQ" />
      <jms-queue name="NgedeRequestQueue" entries="java:/jms/queue/NgedeRequestQueue" durable="true" />
      ...
      <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm" />
      <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" />
      <connection-factory name="NgedeConnectionFactory" entries="java:jboss/exported/jms/NgedeConnectionFactory" connectors="http-connector" />
      <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa" />
   </server>
</subsystem>

Наша потребительская конфигурация Spring:

<!-- Listener Definition -->
<bean id="messageListenerRequest" class="it.eng.ngede.jms.consumer.NationalApplicationRequestConsumer"/>

<bean id="NgedeRequestQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:/jms/queue/NgedeRequestQueue" />
    <property name="jndiTemplate" ref="jnditemplate" />
</bean>

<bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:/ConnectionFactory" />
    <property name="jndiTemplate" ref="jnditemplate" />
</bean>

<bean id="jnditemplate" class="org.springframework.jndi.JndiTemplate">
    <property name="environment">
        <props>
            <prop key="java.naming.factory.initial">org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory</prop>
        </props>
    </property>
</bean>

<!-- JmsContainer Definition -->
<bean id="jmsContainerRequest" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
    <property name="connectionFactory" ref="connectionFactory" />
    <property name="destination" ref="NgedeRequestQueue" />
    <property name="messageListener" ref="messageListenerRequest" />
    <property name="concurrentConsumers" value="1" />
</bean>

Answer 1

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

Если вы хотите другое поведение, тогда я рекомендую установить consumerWindowSize=0 на URL соединения, чтобы потребители не буферизировали сообщения. Конечно, это может снизить пропускную способность сообщения, но это может даже не иметь значения для вашего варианта использования.