Thanks for the reply but I still not clear on what I will put in my
activemq.xml file for the physicalName attribute of the tempQueue element.
What is in the string that replyQWildcard.getPhysicalName() returns?

I'm not sure why you think I would need two non-duplex networkConnectors but
I have a limitation in that the hub can connect to the spokes but not the
other way around. I'm therefore limited to a duplex networkConnector that is
created on the hub. 

I was thinking I could do it like this : 

      <networkConnector name="acme" uri="static:(ssl://server.acme.com...
duplex="true">
        <staticallyIncludedDestinations>
          <queue physicalName="TO_SPOKE.SERVER_ACME_COM.ASYNC_MSGS"/>
          <queue physicalName="TO_HUB.ASYNC_MSGS"/>
          <queue physicalName="TO_HUB.SYNC_REQ"/>
        </staticallyIncludedDestinations>
      </networkConnector>

      <dynamicallyIncludedDestinations>
           <queue physicalName="SHOULD_NEVER_EXIST"/>
      </dynamicallyIncludedDestinations>

In case it isn't obvious... the spoke sends the req/reply message to the hub
via the TO_HUB.SYNC_REQ queue. The only consumers on that queue (on the
spoke) are for the hub's networkConnector thus ensuring the messages placed
in that queue go to the hub for processing. The queue SHOULD_NEVER_EXIST
should never exist thus ensuring that no dynamically created queues are
shared.

What I would need then is a policy that allows the dynamically created
tempQueue that is created on the spoke when it puts a req/reply message in
TO_HUB.SYNC_REQ to be shared between the hub and that one spoke.

Maybe the policy will also render the <dynamicallyIncludedDestinations>
entry above unnecessary. That would be even better.

Thanks again!    







--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4700339.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to