Reply message not forwarded across temporary bridged destination

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Reply message not forwarded across temporary bridged destination

azdvorak
After upgrading from ActiveMQ 5.6 to 5.10, reply messages (initiated from a request / reply transaction) are not being forwarded across the temporary destination created for the reply message.

Setup:

*AMQ-A and AMQ-B are configured in a static network of brokers (configuration below).
*Distributed queue, "test.distributed.queue", will be used for communication.
*Consumer (that is to handle request / reply) is consuming on AMQ-A "test.distributed.queue"

Observed Behavior:

*A request/reply message is published to AMQ-B "test.distributed.queue"
**The replyTo Temporary Queue is created, and a consumer is attached to destination. I see it instantiated on both AMQ brokers via DEBUG level logging.
*The message is forwarded across the network of brokers : AMQ-B > AMQ-A "test.distributed.queue"
*The Consumer receives the message & performs the business logic task
*The Consumer sends response to the temporary destination on AMQ-A
** PROBLEM: The message is not forwarded to AMQ-B where the producer is listening for the response.
*The timeout interval expires
*The temporary destination is destroyed
**I see the message is purged in the AMQ-A log files as the temp destination is destroyed.

With ActiveMQ 5.6 the reply message is forwarded across the temporary destination (AMQ-A > AMQ-B) such that the original producer was able to consume the response. When I turn on debug logging I do not see any errors or warnings. There is simply a lack of action (forwarding of the message).

Is this a regression and/or did the behavior change?
Is there something we need to change in our configuration (server or client)?

Please let me know if I can provide any more information. Log levels, environment details etc.

Here is our ActiveMQ broker (server) configuration for both AMQ-A and AMQ-B:

<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:amq="http://activemq.apache.org/schema/core"
  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-2.0.xsd
  http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd
  http://activemq.apache.org/camel/schema/spring http://activemq.apache.org/camel/schema/spring/camel-spring.xsd">

   
    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
                <list>
                        <value>file:///${activemq.base}/conf/credentials.properties</value>
                        <value>file:/opt/company/activemq/config/activemq.properties</value>
                        <value>file:/etc/opt/company/activemq/activemq.properties</value>
                </list>
        </property>
    </bean>

    <broker xmlns="http://activemq.apache.org/schema/core" 
            brokerName="CompanyActiveMQ"
            deleteAllMessagesOnStartup="false"
            advisorySupport="true">


       
       <destinationPolicy>
           <policyMap>
                <policyEntries>
                    <policyEntry
                       queue="com.company.product.channels.>"
                       producerFlowControl="false"
                       memoryLimit="100mb" >

                       <deadLetterStrategy>
                           <individualDeadLetterStrategy processExpired="false" />
                       </deadLetterStrategy> 
                    </policyEntry>

                </policyEntries>
            </policyMap>
        </destinationPolicy> 

       
        <managementContext>
            <managementContext
                connectorPort="1099"
                jmxDomainName="org.apache.activemq"
                createConnector="false" />
        </managementContext>


       
        <networkConnectors>
                <networkConnector name="activemqNetworkConnector" decreaseNetworkConsumerPriority="true" networkTTL="2" uri="static:(tcp://${remote.network.host}:${remote.network.port})">
                        <dynamicallyIncludedDestinations>
                                <queue physicalName="com.company.product.channels.test.distributed.queue"/>
                        </dynamicallyIncludedDestinations>
                </networkConnector>
        </networkConnectors>


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

       
        <plugins>
           <statisticsBrokerPlugin />
        </plugins>


         <sslContext>
            <sslContext
                keyStore="file:${activemq.base}/conf/broker.ks"
                keyStorePassword="password"
                trustStore="file:${activemq.base}/conf/broker.ts"
                trustStorePassword="password"/>
        </sslContext>

       
        <systemUsage>
            <systemUsage sendFailIfNoSpace="true"> 
                <memoryUsage>
                    <memoryUsage limit="100 mb" percentUsageMinDelta="20" />
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="2 gb" name="foo"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="200 mb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>

       
        <transportConnectors>
            <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" updateClusterClients="false" rebalanceClusterClients="false" updateClusterClientsOnRemove="false"/>
           
             
        </transportConnectors>

    </broker>
   
   
</beans>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
Your <dynamicallyIncludedDestinations> doesn't appear to include any rule
that would result in messages and subscriptions on the temporary reply
queue being bridged between the brokers; it looks to me like you're only
bridging the request queue.

On Mon, Dec 8, 2014 at 3:56 PM, azdvorak <[hidden email]> wrote:

> After upgrading from ActiveMQ 5.6 to 5.10, reply messages (initiated from a
> request / reply transaction) are not being forwarded across the temporary
> destination created for the reply message.
>
> Setup:
>
> *AMQ-A and AMQ-B are configured in a static network of brokers
> (configuration below).
> *Distributed queue, "test.distributed.queue", will be used for
> communication.
> *Consumer (that is to handle request / reply) is consuming on AMQ-A
> "test.distributed.queue"
>
> Observed Behavior:
>
> *A request/reply message is published to AMQ-B "test.distributed.queue"
> **The replyTo Temporary Queue is created, and a consumer is attached to
> destination. I see it instantiated on both AMQ brokers via DEBUG level
> logging.
> *The message is forwarded across the network of brokers : AMQ-B > AMQ-A
> "test.distributed.queue"
> *The Consumer receives the message & performs the business logic task
> *The Consumer sends response to the temporary destination on AMQ-A
> ** PROBLEM: The message is not forwarded to AMQ-B where the producer is
> listening for the response.
> *The timeout interval expires
> *The temporary destination is destroyed
> **I see the message is purged in the AMQ-A log files as the temp
> destination
> is destroyed.
>
> With ActiveMQ 5.6 the reply message is forwarded across the temporary
> destination (AMQ-A > AMQ-B) such that the original producer was able to
> consume the response. When I turn on debug logging I do not see any errors
> or warnings. There is simply a lack of action (forwarding of the message).
>
> Is this a regression and/or did the behavior change?
> Is there something we need to change in our configuration (server or
> client)?
>
> Please let me know if I can provide any more information. Log levels,
> environment details etc.
>
> Here is our ActiveMQ broker (server) configuration for both AMQ-A and
> AMQ-B:
>
> <beans
>   xmlns="http://www.springframework.org/schema/beans"
>   xmlns:amq="http://activemq.apache.org/schema/core"
>   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-2.0.xsd
>   http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd
>   http://activemq.apache.org/camel/schema/spring
> http://activemq.apache.org/camel/schema/spring/camel-spring.xsd">
>
>
>     <bean
>
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
>         <property name="locations">
>                 <list>
>
> <value>file:///${activemq.base}/conf/credentials.properties</value>
>
> <value>file:/opt/company/activemq/config/activemq.properties</value>
>
> <value>file:/etc/opt/company/activemq/activemq.properties</value>
>                 </list>
>         </property>
>     </bean>
>
>     <broker xmlns="http://activemq.apache.org/schema/core"
>             brokerName="CompanyActiveMQ"
>             deleteAllMessagesOnStartup="false"
>             advisorySupport="true">
>
>
>
>        <destinationPolicy>
>            <policyMap>
>                 <policyEntries>
>                     <policyEntry
>                        queue="com.company.product.channels.>"
>                        producerFlowControl="false"
>                        memoryLimit="100mb" >
>
>                        <deadLetterStrategy>
>                            <individualDeadLetterStrategy
> processExpired="false" />
>                        </deadLetterStrategy>
>                     </policyEntry>
>
>                 </policyEntries>
>             </policyMap>
>         </destinationPolicy>
>
>
>         <managementContext>
>             <managementContext
>                 connectorPort="1099"
>                 jmxDomainName="org.apache.activemq"
>                 createConnector="false" />
>         </managementContext>
>
>
>
>         <networkConnectors>
>                 <networkConnector name="activemqNetworkConnector"
> decreaseNetworkConsumerPriority="true" networkTTL="2"
> uri="static:(tcp://${remote.network.host}:${remote.network.port})">
>                         <dynamicallyIncludedDestinations>
>                                 <queue
> physicalName="com.company.product.channels.test.distributed.queue"/>
>                         </dynamicallyIncludedDestinations>
>                 </networkConnector>
>         </networkConnectors>
>
>
>          <persistenceAdapter>
>
>              <kahaDB directory="${activemq.base}/data/kahadb" />
>         </persistenceAdapter>
>
>
>         <plugins>
>            <statisticsBrokerPlugin />
>         </plugins>
>
>
>          <sslContext>
>             <sslContext
>                 keyStore="file:${activemq.base}/conf/broker.ks"
>                 keyStorePassword="password"
>                 trustStore="file:${activemq.base}/conf/broker.ts"
>                 trustStorePassword="password"/>
>         </sslContext>
>
>
>         <systemUsage>
>             <systemUsage sendFailIfNoSpace="true">
>                 <memoryUsage>
>                     <memoryUsage limit="100 mb" percentUsageMinDelta="20"
> />
>                 </memoryUsage>
>                 <storeUsage>
>                     <storeUsage limit="2 gb" name="foo"/>
>                 </storeUsage>
>                 <tempUsage>
>                     <tempUsage limit="200 mb"/>
>                 </tempUsage>
>             </systemUsage>
>         </systemUsage>
>
>
>         <transportConnectors>
>             <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"
> updateClusterClients="false" rebalanceClusterClients="false"
> updateClusterClientsOnRemove="false"/>
>
>
>         </transportConnectors>
>
>     </broker>
>
>
> </beans>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

azdvorak
Thank you, I was able to bridge all destinations via <queue physicalName=">"/> to confirm this will bridge temp destinations. Because temp destinations use the brokerID in their name, is there a common convention to specify only temp destinations via <dynamicallyIncludedDestinations />?
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
I'm not aware of one, though I've never actually used temp destinations so
someone else might know of something I don't know about.

If there's not, you might want to submit a JIRA requesting that
ActiveMQDestination.TEMP_DESTINATION_NAME_PREFIX be made modifiable so you
can prefix all temp destinations with something like "ID:TEMP." instead of
just "ID:", which I think would let you explicitly include (or exclude)
temp destinations across the networkConnector.


On Tue, Dec 9, 2014 at 11:14 AM, azdvorak <[hidden email]> wrote:

> Thank you, I was able to bridge all destinations via <queue
> physicalName=">"/> to confirm this will bridge temp destinations. Because
> temp destinations use the brokerID in their name, is there a common
> convention to specify only temp destinations via
> <dynamicallyIncludedDestinations />?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4688623.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

azdvorak
Thank you for your input so far, it has been helpful. Although I was able to verify including all destinations (via wildcard) does indeed bridge temporary destinations, I do not believe this is the intended solution for the following reasons:

1) temp destinations are created dynamically and use the BrokerID in the name, so having to specify a queue in <dynamicallyIncludedDestinations/> is not intuitive. If there is a temp destination prefix that can be used that would be helpful and I could use that for now.
2) The second reason being: There is a configuration option "bridgeTempDestinations" set on the NetworkConnector as documented here http://activemq.apache.org/networks-of-brokers.html This is set to "true" by default and leads me to believe this is the proper way to bridge temporary destinations. Furthermore when I set this to false I do not see the destination created on both brokers. Where as if I set the value to true, I can see the destination instantiated in both broker logs.

If anyone has additional insight I would greatly appreciate it. Thanks again.
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

azdvorak
My solution is to leave <dynamicallyIncludedDestinations />empty (which means all destinations not in the excluded list will be forwarded) and use the <excludedDestinations /> element to exclude destinations that are not to be bridged.

http://activemq.apache.org/networks-of-brokers.html
excludedDestinations - destinations matching this list won't be forwarded across the network
dynamicallyIncludedDestinations - destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded

-Alex
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
I agree that there's probably some improvement possible here; I'd encourage
you to think about how you'd want it to work and submit an enhancement
request, to make this configuration easier for you and for the next person.
On Dec 10, 2014 4:51 PM, "azdvorak" <[hidden email]> wrote:

> My solution is to leave <dynamicallyIncludedDestinations />empty (which
> means
> all destinations not in the excluded list will be forwarded) and use the
> <excludedDestinations /> element to exclude destinations that are not to be
> bridged.
>
> http://activemq.apache.org/networks-of-brokers.html
> excludedDestinations - destinations matching this list won't be forwarded
> across the network
> dynamicallyIncludedDestinations - destinations that match this list will be
> forwarded across the network n.b. an empty list means all destinations not
> in the exluded list will be forwarded
>
> -Alex
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4688706.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

gtully
In reply to this post by azdvorak
For 1) there is a unit test that shows how to achieve a bridge with no
advisories - so statically configured - that can allow temp dests using a
naming prefix and uses destination gc to tidy up.
https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/RequestReplyNoAdvisoryNetworkTest.java

For 2) the bridgeTempDestinations option is the way to go, but due to the
nature of temp dests (being tied to a connection, or bridge connection) in
the event of a bridge disconnect - all bets are off. Even with clients
using failover, there are inherent races in recreating destinations and
propagating information about their creation.
There is a good example of the usage and limitations  in
https://github.com/apache/activemq/blob/d54e0d6ab590b6a6148a5e2629c45b95d3f40eb8/activemq-unit-tests/src/test/java/org/apache/activemq/network/NetworkFailoverTest.java

If you really care about replies, consider using persistent destinations.

On 10 December 2014 at 00:00, azdvorak <[hidden email]> wrote:

>
> Thank you for your input so far, it has been helpful. Although I was able
> to
> verify including all destinations (via wildcard) does indeed bridge
> temporary destinations, I do not believe this is the intended solution for
> the following reasons:
>
> 1) temp destinations are created dynamically and use the BrokerID in the
> name, so having to specify a queue in <dynamicallyIncludedDestinations/> is
> not intuitive. If there is a temp destination prefix that can be used that
> would be helpful and I could use that for now.
> 2) The second reason being: There is a configuration option
> "bridgeTempDestinations" set on the NetworkConnector as documented here
> http://activemq.apache.org/networks-of-brokers.html This is set to "true"
> by
> default and leads me to believe this is the proper way to bridge temporary
> destinations. Furthermore when I set this to false I do not see the
> destination created on both brokers. Where as if I set the value to true, I
> can see the destination instantiated in both broker logs.
>
> If anyone has additional insight I would greatly appreciate it. Thanks
> again.
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4688631.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Gregg Saffell
I just upgraded from 5.5 to 5.10 and got bit by this one too. What a pain. I am glad to see it is still possible to both restrict dynamically included destinations and still use temp queues however, I do not understand the unit test that has been presented as an example of how to do that.

My questions are:

1) What does "replyQWildcard.getPhysicalName()" return? (I don't generate my activemq.xml files via code so I don't know what I should be putting in the xml file based on that example.)

2) I have a hub-and-spoke architecture where the hub connects to the spokes and the in/out message is produced on the spoke. How do I modify the example such that the hub (the broker with the networkConnector) can reply via the temp queue that is created on the spoke?

3) I don't see any documentation or examples regarding a <tempQueue> element. Is it buried somewhere and I'm just not finding it? I tried several google searches to no avail.

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
In reply to this post by gtully
Gary's recommendation to follow the unit test was explicitly for the
situation where you are trying "to achieve a bridge with no advisories - so
statically configured"; is that actually what you're looking for?  If not,
why are you trying to follow it instead of using the
dynamicallyIncludedDestinations/dynamicallyExcludedDestinations and
bridgeTempDestinations settings referenced earlier in the thread?

Tim

On Mon, Jul 27, 2015 at 8:47 AM, [hidden email] <
[hidden email]> wrote:

> I just upgraded from 5.5 to 5.10 and got bit by this one too. What a pain.
> I
> am glad to see it is still possible to both restrict dynamically included
> destinations and still use temp queues however, I do not understand the
> unit
> test that has been presented as an example of how to do that.
>
> My questions are:
>
> 1) *What does "replyQWildcard.getPhysicalName()" return?* (I don't generate
> my activemq.xml files via code so I don't know what I should be putting in
> the xml file based on that example.)
>
> 2) I have a hub-and-spoke architecture where the hub connects to the spokes
> and the in/out message is produced on the spoke. *How do I modify the
> example such that the hub (the broker with the networkConnector) can reply
> via the temp queue that is created on the spoke?*
>
> 3) I don't see any documentation or examples regarding a <tempQueue>
> element. *Is it buried somewhere and I'm just not finding it?* I tried
> several google searches to no avail.
>
> Thanks!
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4699927.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Gregg Saffell
Yes, I want to use statically defined queues exclusively.  The hub is in NY and the spokes are all around the world, network outages are not rare and one of our uses for AMQ is propagating usage data to a central location. As a result, we have a long expiration on the messages (2 weeks) and want them to collect on the spokes even when the hub is not connected.  

We have queues that exist just at the hub and one spoke (for messages going to the spoke) and queues that exist at all sites (for messages going to the hub). I'm using <staticallyIncludedDestinations> to ensure only the queues relevant to a particular spoke are created there.

In my app, there should be no dynamically created queues. As a precaution, I would like to prevent any such queues that do get created (say, via a programming error or a bug in AMQ) from being replicated to any spokes.

Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
Thanks for clarifying your use-case.

In response to your original questions:

   1. getPhysicalName() returns a String, which allows wildcards (*, >, and
   I think <, though that might be a 5.11 feature, I don't remember).
   2. The staticallyIncludedDestinations attribute controls which
   destinations the current broker is allowed to forward messages for to the
   broker at the other end of the networkConnector.  This means that you'll
   want two non-duplex networkConnectors per hub/spoke pair, with each one
   including the destinations that should go to the other broker.
   3. I thought I'd seen such a thing in the past, but couldn't find it in
   response to a previous question and I believe that person got things
   working successfully without it.  So you may be able to successfully ignore
   it; at least give it a shot without and see how it goes.

BTW, http://activemq.apache.org/networks-of-brokers.html has some examples
of the staticallyIncludedDestinations attribute in a XML file, if you're
still not quite sure what it should look like.

Hope this gets you to a working configuration; let us know what's not
working if it doesn't.

Tim

On Thu, Jul 30, 2015 at 3:26 PM, Gregg Saffell <[hidden email]>
wrote:

> Yes, I want to use statically defined queues exclusively.  The hub is in NY
> and the spokes are all around the world, network outages are not rare and
> one of our uses for AMQ is propagating usage data to a central location. As
> a result, we have a long expiration on the messages (2 weeks) and want them
> to collect on the spokes even when the hub is not connected.
>
> We have queues that exist just at the hub and one spoke (for messages going
> to the spoke) and queues that exist at all sites (for messages going to the
> hub). I'm using <staticallyIncludedDestinations> to ensure only the queues
> relevant to a particular spoke are created there.
>
> In my app, there should be no dynamically created queues. As a precaution,
> I
> would like to prevent any such queues that do get created (say, via a
> programming error or a bug in AMQ) from being replicated to any spokes.
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4700169.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Gregg Saffell
This post was updated on .
Thanks for the reply but I'm 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? (Just knowing what it might contain doesn't help unless maybe you are telling me to use a wildcard that matches everything as the physicalName? Maybe that allows forwarding on all temp queues?)

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>

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

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!    



Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Gregg Saffell
Never mind my most recent questions. I found a post where Gary Tully said that advisory messages should be turned off when the number of brokers gets into the double digits. We are approaching triple digits so we've decided to just remove the use of temp queues with request/reply messages and turn off advisory messages entirely.
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Rajesh Malla
Hello

We are having similar problem in request/reply pattern with temp queue. we
are not getting response when we are using addDynamicallyIncludedDestination
on networkconnector with some queues.

so can anybody suggest what pattern to use if we are using in java code. for
example :

NetworkConnector networkConnector = new DiscoveryNetworkConnector(uri);
networkConnector.addDynamicallyIncludedDestination(???)

we tried with new ActiveMQQueue(">")  but still not able to receive response
messages. Please help us.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Rajesh Malla
Can anybody please provide reply for this. What pattern we need to use ?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Reply message not forwarded across temporary bridged destination

Tim Bain
As described by azdvorak on 12/9/2014 and documented on
http://activemq.apache.org/networks-of-brokers.html, the
bridgeTempDestinations configuration option is the proper way to
dynamically bridge temp destinations.

The two previous posters were both trying to bridge temp destinations
statically whereas you're trying to do it dynamically (the simpler
scenario), so the behavior you're seeing is not related to the questions
they were asking. So if something's not working, please follow up in one of
the three other threads you currently have open, or start a new thread if
there's a reason your questions should not go into your existing threads;
please do not continue to hijack this unrelated thread.

Tim

On Sat, Feb 24, 2018 at 4:57 PM, Rajesh Malla <[hidden email]> wrote:

> Can anybody please provide reply for this. What pattern we need to use ?
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>