activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Fernandez <joe.fernan...@ttmsolutions.com>
Subject Re: Not quite sure where to go next - network bridging, reliable delivery, store and forward.
Date Thu, 02 Oct 2008 15:02:18 GMT

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-topic-subscription.html



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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Not-quite-sure-where-to-go-next---network-bridging%2C-reliable-delivery%2C-store-and-forward.-tp19764204p19781071.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message