from your network connectors config, remove:
 <networkConnector name="topicsOnly" networkTTL="6"
uri="static:(tcp://10.0.0.178:61616,tcp://10.0.0.179:61616)"
conduitSubscriptions="true">

b/c this is bridging all destinations as there are no excludes, so you
have two paths to each broker which will complicate it a bit.
On the ttl, this should be the minimum number of hops you require, I
don't see why you want 6 in there. 3 or 2 should be sufficient.

What is your intention with three brokers? If the intention is to
build a mesh topology, then all brokers can talk directly to each
other and a ttl of 1 is sufficient.
If you are building a ring, then a message can have multiple routes,
but ttl=2 is sufficient.

If your local consumer and network consumers are competing, then use
decreaseNetworkConsumerPriority=true in the network connector so that
local consumers get priority.

It looks like you need to go back to first principals and understand
what is being configured and the intent of every option that you
choose.

Maybe have a read of
http://blog.garytully.com/2012/07/activemq-broker-networks-think-demand.html
to get a better understanding of the principals.

hope this helps.

On 23 October 2012 02:44, ndmigration <raghu_madab...@americantours.com> wrote:
> Hello,
>
> I have set up 3 brokers in network of brokers. BrokerA connects to BrokerB,
> BrokerC, and BrokerB connects to BrokerA, BrokerC, and BrokerC connects to
> BrokerB, BrokerA. I tried duplex on all the brokers to reduce the
> configuration but that didn't help. My set up involves consumers and
> producers in request/response model. Producers on client side sends messages
> to REQUEST queue and Consumers on server side receive messages, process it
> and sends the response to RESPONSE queue where the consumers on client side
> are listening. Please note that I'm not using temporary queues for
> Request/Response model but physical queues.
>
> The request and response is based on correlationID so that the server
> response reaches proper consumer on the client side. The NOB is forwarding
> client request messages across the brokers, severs process them and put back
> the message on the response queue. However, the consumers are timing out
> waiting for the responses.
>
> *Example:*
>
> Consumer1 randomly connects to a broker using failover protocol and sends a
> message to BrokerB. BrokerB forwards the message to BrokerC and the message
> is processed by the consumer on the server that is listening on BrokerC. The
> response message is put back on the RESPONSE queue on BrokerC but not sure
> what's happening after that. The consumer on the client side waiting on
> BrokerB is timing out. I have set 3 minutes as timeout on receive() method,
> and 2 minutes for message TTL. Again, the server immediately process the
> messages and so there is no delay in there. I'm suspecting that the messages
> in RESPONSE queue within the brokers are not forwarding properly to reach
> the consumer which is using correlation selector key. I have also verified
> the uniqueness of correlationid so that no other consumer can consume the
> message other than the intended consumer.
>
> I have tried all suggestions: making duplex to true, ProducerControl to
> false, allocated more memory, changed networkTTL to 6, added
> receiveWhenNoConsumers=true flag with useCache=false and auditEnable=false.
> I've been fighting with this for the past few days before seeking help.
>
> *One of my broker config:*
>
> <destinationPolicy>
>             <policyMap>
>               <policyEntries>
>                 <policyEntry topic=">" producerFlowControl="true"
> memoryLimit="10mb">
>                   <pendingSubscriberPolicy>
>                     <vmCursor />
>                   </pendingSubscriberPolicy>
>                 </policyEntry>
>                   <policyEntry queue=">" producerFlowControl="false" 
> memoryLimit="10mb"
> enableAudit="false" useCache="false">
>
>                         <networkBridgeFilterFactory>
>                                 <conditionalNetworkBridgeFilterFactory 
> replayWhenNoConsumers="true" />
>                         </networkBridgeFilterFactory>
>                          <deadLetterStrategy>
>                                  <sharedDeadLetterStrategy 
> processExpired="false" />
>                          </deadLetterStrategy>
>                    </policyEntry>
>               </policyEntries>
>             </policyMap>
>         </destinationPolicy>
>
>
>         <networkConnectors>
>                         <networkConnector name="queuesOnly" networkTTL="6"
> uri="static:(tcp://10.0.0.178:61616,tcp://10.0.0.179:61616)"
> conduitSubscriptions="false">
>                                 <dynamicallyIncludedDestinations>
>                                         <queue physicalName=">"/>
>                                 </dynamicallyIncludedDestinations>
>                         </networkConnector>
>                         <networkConnector name="topicsOnly" networkTTL="6"
> uri="static:(tcp://10.0.0.178:61616,tcp://10.0.0.179:61616)"
> conduitSubscriptions="true">
>                         </networkConnector>
>                 </networkConnectors>
>
>
>         <transportConnectors>
>             <transportConnector name="openwire" uri="tcp://10.0.0.177:61616"
> />
>         </transportConnectors>
>
> Thanks,
> Ragu
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Request-Response-Model-Not-Working-in-Network-of-Brokers-Please-Help-tp4658071.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



-- 
http://redhat.com
http://blog.garytully.com

Reply via email to