2015-01-15 2 views
0

У меня есть сеть брокеров по полной топологии графа с тремя узлами на разных серверах: A, B и C. Каждый брокер имеет прикрепленный производитель и для целей тестирования только один не-брокер потребитель на брокере C. Поскольку я использую топологию Full Graph, каждый брокер также имеет брокер-потребитель для каждого из других узлов.ActiveMQ не распространяет сообщения между брокерами

Проблема: A получает несколько сообщений. Я ожидаю, что он отправит эти сообщения брокеру C, к которому прилагается «настоящий» потребитель. Этого не происходит, брокер A сохраняет эти сообщения до тех пор, пока «настоящий» потребитель не подключится к нему.

Что случилось с моей конфигурацией (или пониманием)?

Я использую ActiveMQ 5.9.0.

Вот мой activemq.xml для брокера А. Это то же самое для B и C, только изменение названия:

<beans 
    xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd 
    http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd"> 

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="broker-A" dataDirectory="${activemq.data}"> 

    <destinationPolicy> 
     <policyMap> 
      <policyEntries> 
       <policyEntry topic="tokio.>"> 
        <subscriptionRecoveryPolicy> 
         <noSubscriptionRecoveryPolicy/> 
        </subscriptionRecoveryPolicy> 
        <pendingMessageLimitStrategy> 
         <constantPendingMessageLimitStrategy limit="1000"/> 
        </pendingMessageLimitStrategy> 
       </policyEntry> 
      </policyEntries> 
     </policyMap> 
    </destinationPolicy> 

    <managementContext> 
     <managementContext createConnector="true"/> 
    </managementContext> 

    <persistenceAdapter> 
     <kahaDB directory="${activemq.data}/kahadb"/> 
    </persistenceAdapter> 

    <systemUsage> 
     <systemUsage> 
      <memoryUsage> 
       <memoryUsage percentOfJvmHeap="70" /> 
      </memoryUsage> 
      <storeUsage> 
       <storeUsage limit="40 gb"/> 
      </storeUsage> 
      <tempUsage> 
       <tempUsage limit="10 gb"/> 
      </tempUsage> 
     </systemUsage> 
    </systemUsage> 

    <networkConnectors> 
     <networkConnector name="linkTo-broker-B" 
          uri="static:(tcp://SRVMSG01:61616)" 
          duplex="true" 
       /> 
     <networkConnector name="linkTo-broker-C" 
          uri="static:(tcp://SRVMSG03:61616)" 
          duplex="true" 
       /> 
    </networkConnectors> 

    <transportConnectors> 
     <transportConnector uri="tcp://localhost:0" discoveryUri="multicast://default"/> 
     <transportConnector name="nio" uri="nio://0.0.0.0:61616" /> 
    </transportConnectors> 

</broker> 

</beans> 

ответ

1

По умолчанию networkTTL 1 (см documentation), поэтому, когда производитель на B публикует сообщение, если оно берет путь к A (который будет выполнять 50% времени в вашей конфигурации, потому что у вас есть брокера, настроенного на круговое вращение между потребителями, больше на секунду), это недопустимо для перенаправления на C. Вы можете исправить проблему, увеличив значение networkTTL, но лучшим решением является установка decreaseNetworkConsumerPriority=true (см. документацию по той же ссылке, что и выше), чтобы сообщения всегда поступали в формате dir насколько это возможно для потребителя, которому они предназначены.

Обратите внимание, что если ваши потребители перемещаются по сетке, это может содержать сообщения как из-за того, что значение networkTTL не допускает дополнительных переходов, а потому, что сообщениям не разрешается обращаться к брокеру, через который они уже прошло. Вы можете обратиться к ним, установив networkTTL на большее значение (например, 20, чтобы быть полностью безопасным) и применив параметр политики replayWhenNoConsumers=true, описанный в разделе «Застрявшие сообщения» на той же странице документации. Ни одна из этих настроек не является абсолютно необходимой, если вы уверены, что ваши потребители никогда не перейдут к другому брокеру, или вы в порядке потеряете несколько сообщений, когда это произойдет.

+0

Это само по себе не работает. Я также должен был указать, как распространение происходит через посредников путем добавления очередей в качестве динамическиIncludedDestinations. –

+1

Я интерпретировал «A получает несколько сообщений», чтобы означать, что некоторые сообщения отправлялись в A, но не все из них были (и что остальные успешно доводили до C), поэтому я даже не считал, что вы можете не пересылать * любые * сообщения. Я рад, что вы поняли это, чтобы найти решение. – Tim

Смежные вопросы