CODEWITHSUNDEEP
jmsactivemq-classic
Luiza Utsch
Luiza Utsch

Reputation: 165

ActiveMQ not distributing messages between brokers

I have a network of brokers on a Complete Graph topology with 3 nodes at different servers: A, B and C. Every broker has a producer attached and, for testing purposes, only one non-broker consumer on broker C. As I'm using the Complete Graph topology every broker also has a broker-consumer for each of the other nodes.

The problem is: A receives a few messages. I expect it to forward those messages to broker C, which has a "real" consumer attached. This is not happening, broker A stores those messages until a "real" consumer connects to it.

What's wrong with my configuration (or understanding)?

I'm using ActiveMQ 5.9.0.

Here's my activemq.xml for broker A. It's the same for B and C, only changing names:

<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>

Upvotes: 0

Views: 1349

Answers (1)

Tim
Tim

Reputation: 2027

By default, networkTTL is 1 (see documentation), so when a producer on B publishes a message, if it takes the path to A (which it will do 50% of the time in your configuration because you've got the broker set up to round-robin between consumers, more on that in a second), it's not allowed to be forwarded to C. You could fix the problem by increasing the value of networkTTL, but the better solution is to set decreaseNetworkConsumerPriority=true (see documentation at same link as above) to ensure that messages always go as directly as possible to the consumer to which they're destined.

Note, however, that if your consumers move around the mesh, this can strand messages both because the networkTTL value won't allow additional forwards and because messages aren't allowed to be resent to a broker through which they've already passed. You can address those by setting networkTTL to a larger value (like 20, to be completely safe) and by applying the replayWhenNoConsumers=true policy setting described in the "Stuck Messages" section of that same documentation page. Neither of those settings is strictly necessary, as long as you're sure your consumers will never move to another broker or you're OK losing a few messages when it does happen.

Upvotes: 1

Related Questions