You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by azdvorak <al...@gmail.com> on 2014/12/08 23:56:58 UTC
Reply message not forwarded across temporary bridged destination
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.
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <ma...@gmail.com> 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
>
Re: Reply message not forwarded across temporary bridged
destination
Posted by Rajesh Malla <ma...@gmail.com>.
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
Re: Reply message not forwarded across temporary bridged
destination
Posted by Rajesh Malla <ma...@gmail.com>.
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
Re: Reply message not forwarded across temporary bridged
destination
Posted by Gregg Saffell <gs...@ilstechnology.com>.
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.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Reply-message-not-forwarded-across-temporary-bridged-destination-tp4688578p4700901.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Reply message not forwarded across temporary bridged
destination
Posted by Gregg Saffell <gs...@ilstechnology.com>.
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.
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <gs...@ilstechnology.com>
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.
>
Re: Reply message not forwarded across temporary bridged
destination
Posted by Gregg Saffell <gs...@ilstechnology.com>.
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.
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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, gsaffell@ilstechnology.com <
gsaffell@ilstechnology.com> 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.
>
Re: Reply message not forwarded across temporary bridged
destination
Posted by "gsaffell@ilstechnology.com" <gs...@ilstechnology.com>.
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.
Re: Reply message not forwarded across temporary bridged
destination
Posted by Gregg Saffell <gs...@ilstechnology.com>.
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-tp4688578p4699928.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Reply message not forwarded across temporary bridged destination
Posted by Gary Tully <ga...@gmail.com>.
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 <al...@gmail.com> 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.
>
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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" <al...@gmail.com> 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.
>
Re: Reply message not forwarded across temporary bridged
destination
Posted by azdvorak <al...@gmail.com>.
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.
Re: Reply message not forwarded across temporary bridged
destination
Posted by azdvorak <al...@gmail.com>.
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.
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <al...@gmail.com> 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.
>
Re: Reply message not forwarded across temporary bridged
destination
Posted by azdvorak <al...@gmail.com>.
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.
Re: Reply message not forwarded across temporary bridged destination
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <al...@gmail.com> 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.
>