You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "gsaffell@ilstechnology.com" <gs...@ilstechnology.com> on 2015/07/27 16:47:37 UTC
Re: Reply message not forwarded across temporary bridged
destination
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 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.
>