activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjørn T Johansen <...@havleik.no>
Subject Re: Problem configuring a "network of brokers"?
Date Thu, 05 Feb 2009 11:01:36 GMT
I had a problem with the destiantion-type (was not set) in my spring listener configuration,
it's working now... (after setting dest.type = topic)

BTJ

On Thu, 5 Feb 2009 10:27:32 +0100
Dejan Bosanac <dejan@nighttale.net> wrote:

> Hi, it should work for topics, the same as for queues. The only problem I
> can anticipate is that you may use non-durable topic subscribers. Check out
> these articles
> 
> http://activemq.apache.org/how-do-durable-queues-and-topics-work.html
> http://activemq.apache.org/why-do-i-not-receive-messages-on-my-durable-topic-subscription.html
> 
> If that is not a problem, try turning on debugging and diagnose what is
> happening.
> 
> Cheers
> --
> Dejan Bosanac
> 
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
> 
> 
> On Wed, Feb 4, 2009 at 6:36 PM, Bjørn T Johansen <btj@havleik.no> wrote:
> 
> > Or maybe I am doing this wrong... I am using same kind of jsm:listener that
> > I use to read messages from a queue... Should this work or do I have to
> > subscribe to a topic som other way? (I can't seem to find any examples on
> > how to read topic messages using Spring...)
> >
> >
> > BTJ
> >
> >
> >
> > Quoting Bjørn T Johansen <btj@havleik.no>:
> >
> >  There is one thing that is still not working...
> >>
> >> I changed the queue <queue physicalName="no.asp.nexstep.xmlfilesall"/>
to
> >> a topic:
> >>
> >>        <topic physicalName="no.asp.nexstep.xmlfilesall"/>
> >>
> >> And it seems to be workin because when posting a message to that topic on
> >> the central server, it is forwarded to both boserver1 and boserver2. But
> >> when a client connects to either boserver1 or boserver2, there is no topic
> >> in the topic queue to be read and I guess I am still missing something?
> >>
> >>
> >> BTJ
> >>
> >> On Wed, 4 Feb 2009 15:31:21 +0100
> >> Bjørn T Johansen <btj@havleik.no> wrote:
> >>
> >>  Hmmm... I might have the config correct... I was confused by the fact
> >>> that all the queues are display on the admin page of both boserver1 and
> >>> boserver2... (but the messages seems to only bo delivered where they are
> >>> supposed to...)
> >>>
> >>> But could any verify that my config is correct? and that there isn't any
> >>> more configuration I should/could use?
> >>>
> >>>
> >>> BTJ
> >>>
> >>> On Wed, 4 Feb 2009 15:06:37 +0100
> >>> Bjørn T Johansen <btj@havleik.no> wrote:
> >>>
> >>> > Hmmm... That's the example I have used but I don't get the config
> >>> correct...
> >>> >
> >>> > The is the config for the central broker:
> >>> >
> >>> > <networkConnector name="bridge_boserver1" uri="static://(tcp://
> >>> 10.4.34.26:61616)" dynamicOnly="true" conduitSubscriptions="false"
> >>> > decreaseNetworkConsumerPriority="false"> <excludedDestinations>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver2"/>
> >>> >                 </excludedDestinations>
> >>> >                 <staticallyIncludedDestinations>
> >>> >                         <queue physicalName="no.asp.nexstep.queue"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver1"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfilesall"/>
> >>> >                 </staticallyIncludedDestinations>
> >>> >                 <duplex>true</duplex>
> >>> >                 <networkTTL>1</networkTTL>
> >>> >             </networkConnector>
> >>> >             <networkConnector name="bridge_boserver2"
> >>> uri="static://(tcp://10.4.34.19:61616)" dynamicOnly="true"
> >>> conduitSubscriptions="false"
> >>> > decreaseNetworkConsumerPriority="false"> <excludedDestinations>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver1"/>
> >>> >                  </excludedDestinations>
> >>> >                  <staticallyIncludedDestinations>
> >>> >                         <queue physicalName="no.asp.nexstep.queue"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver2"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfilesall"/>
> >>> >                 </staticallyIncludedDestinations>
> >>> >                 <duplex>true</duplex>
> >>> >                 <networkTTL>1</networkTTL>
> >>> >             </networkConnector>
> >>> >         </networkConnectors>
> >>> >
> >>> >
> >>> >
> >>> > And this is for the boserver1 broker..:
> >>> >
> >>> > <networkConnectors>
> >>> >             <!-- by default just auto discover the other brokers
-->
> >>> >             <!--<networkConnector name="default-nc"
> >>> uri="multicast://default"/>-->
> >>> >             <!-- Example of a static configuration:
> >>> >             <networkConnector name="host1 and host2"
> >>> uri="static://(tcp://host1:61616,tcp://host2:61616)"/>
> >>> >             -->
> >>> >             <networkConnector name="bridge" uri="static://(tcp://
> >>> 10.4.34.10:61616)" dynamicOnly="true" conduitSubscriptions="false"
> >>> > decreaseNetworkConsumerPriority="false">
> >>> <staticallyIncludedDestinations>
> >>> >                         <queue physicalName="no.asp.nexstep.queue"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver1"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfilesall"/>
> >>> >                 </staticallyIncludedDestinations>
> >>> >                 <duplex>true</duplex>
> >>> >                 <networkTTL>1</networkTTL>
> >>> >             </networkConnector>
> >>> >         </networkConnectors>
> >>> >
> >>> >
> >>> > And this is for the boserver2 broker..:
> >>> >
> >>> > <networkConnectors>
> >>> >             <!-- by default just auto discover the other brokers
-->
> >>> >             <!-- Example of a static configuration:
> >>> >             <networkConnector name="host1 and host2"
> >>> uri="static://(tcp://host1:61616,tcp://host2:61616)"/>
> >>> >             -->
> >>> >             <networkConnector name="bridge" uri="static://(tcp://
> >>> 10.4.34.10:61616)" dynamicOnly="true" conduitSubscriptions="false"
> >>> > decreaseNetworkConsumerPriority="false">
> >>> <staticallyIncludedDestinations>
> >>> >                         <queue physicalName="no.asp.nexstep.queue"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfiles_boserver2"/>
> >>> >                         <queue
> >>> physicalName="no.asp.nexstep.xmlfilesall"/>
> >>> >                 </staticallyIncludedDestinations>
> >>> >                 <duplex>true</duplex>
> >>> >                 <networkTTL>1</networkTTL>
> >>> >             </networkConnector>
> >>> >         </networkConnectors>
> >>> >
> >>> >
> >>> > The problem is that all the queues are available on both boserver1
> >>> broker and boserv2 broker (I thought that boserver1 should not see the
> >>> bosever2
> >>> > queue and boserver2 should not have seen the boserver1 queue but they
> >>> do).
> >>> >
> >>> > What I want is messages posted on boserver1 should only reach the
> >>> central broker (and not the boserver2 broker). Also messages posted on the
> >>> > central broker should reach either boserver1 or boserver2 (and not
> >>> based on a random outcome which). Also some messages posted on the central
> >>> > broker should be delivered to both boserver1 and boserver2 broker...
> >>> >
> >>> >
> >>> > So what am I missing?
> >>> >
> >>> >
> >>> >
> >>> > BTJ
> >>> >
> >>> >
> >>> > On Wed, 4 Feb 2009 14:48:23 +0100
> >>> > Dejan Bosanac <dejan@nighttale.net> wrote:
> >>> >
> >>> > > Hi Bjorn,
> >>> > >
> >>> > > this is exactly what network of brokers are supposed to do. Note
that
> >>> broker
> >>> > > will forward a message to other broker only if there is a consumer
> >>> for that
> >>> > > destination on the other broker. You can ensure that messages
go only
> >>> to the
> >>> > > next broker in the network, by setting networkTTL parameter to
1. You
> >>> can
> >>> > > also exclude some destinations for a certain network connector
and
> >>> ensure
> >>> > > that messages are never forwarded. Take a look at
> >>> > > http://activemq.apache.org/networks-of-brokers.html for more
> >>> detailed
> >>> > > examples.
> >>> > >
> >>> > > Hope this helps
> >>> > > --
> >>> > > Dejan Bosanac
> >>> > >
> >>> > > Open Source Integration - http://fusesource.com/
> >>> > > ActiveMQ in Action - http://www.manning.com/snyder/
> >>> > > Blog - http://www.nighttale.net
> >>> > >
> >>> > >
> >>> > > On Wed, Feb 4, 2009 at 2:24 PM, Bjørn T Johansen <btj@havleik.no>
> >>> wrote:
> >>> > >
> >>> > > > Not sure how to configure this or if it's even possible with
> >>> ActiveMQ.
> >>> > > > The system we are want to use is as follows.:
> >>> > > >
> >>> > > > One central broker.
> >>> > > > X number of "client brokers", placed in different location
(over
> >>> WAN) but
> >>> > > > with contact to the central broker
> >>> > > >
> >>> > > > The clients connects to the "client brokers" and when they
post a
> >>> message
> >>> > > > to a "client broker" it should be forwarded to the central
broker
> >>> where
> >>> > > > someone should consume it. And when posting a message to
the
> >>> central
> >>> > > > broker, it should be forwarded to one of the "client brokers"
> >>> (depending on
> >>> > > > which
> >>> > > > queue it's posted on), and a client can read it from the
"client
> >>> broker"
> >>> > > > I.e no messages should transfer from one "client broker"
to another
> >>> "client
> >>> > > > broker", all messages should just travel between the central
broker
> >>> and
> >>> > > > one of the "client brokers".
> >>> > > >
> >>> > > > The reason we want a configuration like this, is so messages
can be
> >>> posted
> >>> > > > even if the network between a client and the central broker
is
> >>> down..
> >>> > > >
> >>> > > > Did that make any sense? Is this possible?
> >>> > > > I have been looking at a network of brokers but as fas as
I can
> >>> see, this
> >>> > > > is more a load balancing configuration and that is not what
we
> >>> want...
> >>> > > >
> >>> > > >
> >>> > > > Regards,
> >>> > > >
> >>> > > > BTJ
> >>> > > >
> >>> > > > --
> >>> > > >
> >>> > > >
> >>> -----------------------------------------------------------------------------------------------
> >>> > > > Bjørn T Johansen
> >>> > > >
> >>> > > > btj@havleik.no
> >>> > > >
> >>> > > >
> >>> -----------------------------------------------------------------------------------------------
> >>> > > > Someone wrote:
> >>> > > > "I understand that if you play a Windows CD backwards you
hear
> >>> strange
> >>> > > > Satanic messages"
> >>> > > > To which someone replied:
> >>> > > > "It's even worse than that; play it forwards and it installs
> >>> Windows"
> >>> > > >
> >>> > > >
> >>> -----------------------------------------------------------------------------------------------

Mime
View raw message