activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas R. Corbin" <thomas.cor...@gmail.com>
Subject Re: Not quite sure where to go next - network bridging, reliable delivery, store and forward.
Date Thu, 02 Oct 2008 20:09:46 GMT
On Thursday 02 October 2008, Joe Fernandez said:
> Are your  'assignments' messages are being sent out as non persistent? If
> so, then that is more than likely your problem.
>
> http://activemq.apache.org/why-do-i-not-receive-messages-on-my-durable-topi
>c-subscription.html

They *should* be persistent, but I'll go back and make sure.

>
> Tom Corbin wrote:
> > On Wednesday 01 October 2008, Joe Fernandez said:
> >> Use care, if you've assigned the multicast uri to all the brokers'
> >> network
> >> and transport connectors. They'll all end up trying to connect to one
> >> another. I think what you may want to consider is more of a hub-n-spoke
> >> topology, where the hub is your master broker. The resulting connections
> >> (spokes) in that topology would have to be 'duplex' in order to
> >> accommodate
> >> two-way traffic.
> >
> > Ok, I've got everything duplex.
> >
> > I'm not using multicast - I couldn't get the windows boxes to allow that.
> > So the embedded brokers all connect to a central broker, in the central
> > office,
> > even the server processes in the central office.
> >
> > I don't really see a way around using the embedded brokers in the field,
> > though.
> >
> > The messages seem to get enqueued in the embedded brokers and then not
> > beyond
> > that, they don't get dequeued when the client on the other end comes up.
> > So
> > it feels as though the subscriptions aren't being communicated or they
> > arent'
> > really durable or something.  But I'm not sure.
> >
> >> conduitSubscriptions
> >> --------------------
> >> This example helps explain “conduitSubscriptions”. Suppose you have two
> >> brokers, A and B that are interconnected. Connected to broker A, you
> >> have a
> >> consumer that subscribes to a queue called Q.TEST. Connected to broker
> >> B, you have two consumers that subscribe to the same queue. Then you
> >> start a producer on broker A that writes 30 messages to Q.TEST. If
> >> conduitSubscriptions=true, 15 messages will be sent to the consumer on
> >> broker A and the resulting 15 messages will be sent to the two consumers
> >> on
> >> broker B. This is because broker A views the two subscriptions on broker
> >> B
> >> as one. If you set conduitSubscriptions to “false”, then each of the
> >> three
> >> consumers is given 10 messages.
> >
> > Wow, that really makes sense.   I guess I'll leave it false.   But it
> > *shouldn't* make any difference since we're sending assignments out to
> > the field
> > on personalized topics - there should only be one consumer for the
> > messages.
> >
> > And only the server processes should be consumers for their particular
> > topics.
> >
> >> duplex
> >> ------
> >> If true, a network connection between 2 brokers will be used to both
> >> produce AND consume messages. In other words, messages can flow in
> >> either direction. This is useful for hub and spoke scenarios when the
> >> hub is behind a firewall or for clients implementing a request/reply
> >> protocol. This is available only for ActiveMQ version 5.0 and higher.
> >
> > I'm using duplex = true.
> >
> >> dynamicOnly
> >> ------------
> >> If set to true, the broker will forward messages to the endpoint broker
> >> (broker at the other end of the connection) only if that endpoint broker
> >> has active consumers.
> >
> > I've got this set to false.   I had actually hoped when I read this that
> > I had
> > it set to true, because it would seem as though it might be the solution
> > to my
> > problem - but it is set to false in all 3 brokers.   Well - maybe I
> > should *try* it true, just to see?
> >
> >> Joe
> >> Get a free ActiveMQ user guide @ http://www.ttmsolutions.com
> >>
> >> Joe Fernandez wrote:
> >> > Are the 'assignments' messages being sent out as non persistent
> >>
> >> messages?
> >>
> >> > Joe
> >> > Get a free ActiveMQ user guide @ http://www.ttmsolutions.com
> >> >
> >> > Tom Corbin wrote:
> >> >> Now, it seems like the recommendation is for Master/Slave for
> >> >> reliable delivery, but I don't think we can do that.
> >> >>
> >> >> We've got field laptops which may or may not have connectivity with
> >>
> >> the
> >>
> >> >> central
> >> >> office, but they want to be able to run the application and have it
> >>
> >> send
> >>
> >> >> messages that get delivered when the network comes up.
> >> >>
> >> >> And the client wants the central office to be able to send
> >> >> assignments to the
> >> >> field whether or not the network to the field laptop is up.
> >> >>
> >> >> So for the field laptops I've set up an embedded broker which then
> >> >> connects to
> >> >> a central office broker.   The reason is that the application won't
> >>
> >> come
> >>
> >> >> up if
> >> >> there isn't a local broker that it can connect to.  If the
> >> >> application is started w/o a local broker or a connection to the
> >> >> central office it doesn't come
> >> >> up.   Plus, I wanted the local message persistence so that the user
> >> >> of the
> >> >> application can trigger messages to be sent even when the connection
> >>
> >> to
> >>
> >> >> the
> >> >> central office isn't present.
> >> >>
> >> >> In the central office we've get server processes also with embedded
> >> >> brokers.
> >> >>
> >> >> I've been fiddling with the setup configuration for the embedded
> >>
> >> brokers
> >>
> >> >> and the
> >> >> central office brokers and I've gotten to the point that messages
> >> >> from the field
> >> >> get sent to the central office on reconnect, but don't get sent from
> >>
> >> the
> >>
> >> >> central
> >> >> office to the field on reconnect.
> >> >>
> >> >> And everything works if everything is connected.   But if the laptop
> >> >> isn't
> >> >> connected to the central office when the central office sends out
> >> >> assignments to
> >> >> the field, then the laptop will never see those messages.
> >> >>
> >> >> I've tried using durable subscription topics, I've tried setting
> >> >> "conduitSubscriptions" to both true and false - and I'm not sure if
I
> >> >> should
> >> >> set it one way for the central office broker and the same or
> >> >> different for the
> >> >> laptop and server process embedded brokers.
> >> >>
> >> >> The network kind of looks like this:
> >> >>
> >> >> Field laptop|---------|central office broker|-----|Server Process|
> >> >>
> >> >> The central office broker is intended to be the "master", in as much
> >>
> >> as
> >>
> >> >> there is
> >> >> a master - this isn't really a master/slave setup.
> >> >>
> >> >> I can use JMX to look at the enqueue/dequeue counts to see where
> >> >> messages are
> >> >> getting hung up - but I am not ever sure why.
> >> >>
> >> >> I had thought that with durable subscriptions, the messages would get
> >> >> sent,
> >> >> but that *seems* not to be the case.
> >> >>
> >> >> I have looked through ActiveMQ bug reports and the online
> >>
> >> documentation.
> >>
> >> >> Of
> >> >> which there is a lot, but I am still quite confused.
> >> >>
> >> >> Seeing as how I'm doing the embedded broker set up in Groovy, rather
> >> >> than in
> >> >> spring or xbean - should I explicitly be using a
> >>
> >> DemandForwardingBridge
> >>
> >> >> as in
> >> >> the ThreeBroker tests?   Or does the underlying code just use it
> >>
> >> anyway?
> >>
> >> >> What would that imply for the activemq.xml config file for the master
> >> >> broker?
> >> >> Is there configuration that explicitly says use a
> >> >> DemandForwardingBridge? Or
> >> >> is the DemandForwardingBridge not the issue?
> >> >>
> >> >> What should these values be set to?
> >> >>
> >> >>                         decreaseNetworkConsumerPriority="false"
> >> >>                         conduitSubscriptions="true"
> >> >>                         bridgeTempDestinations="true"
> >> >>                         duplex="true"
> >> >>
> >> >> Sorry for such a newbie set of questions and so long an email.


Mime
View raw message