You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Thomas R. Corbin" <th...@gmail.com> on 2008/10/01 18:25:17 UTC
Not quite sure where to go next - network bridging, reliable delivery, store and forward.
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.
Re: Not quite sure where to go next - network bridging, reliable delivery, store and forward.
Posted by "Thomas R. Corbin" <th...@gmail.com>.
On Wednesday 01 October 2008, Thomas R. Corbin said:
> 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.
I forgot to mention that I'm on 5.1.0
--
Card #1. Uncle Bob’s Three Laws
• Write no production code except to pass a failing test.
• Write only enough of a test to demonstrate a failure.
• Write only enough production code to pass the test.
Re: Not quite sure where to go next - network bridging, reliable delivery, store and forward.
Posted by "Thomas R. Corbin" <th...@gmail.com>.
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.
Re: Not quite sure where to go next - network bridging, reliable
delivery, store and forward.
Posted by Joe Fernandez <jo...@ttmsolutions.com>.
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.
Re: Not quite sure where to go next - network bridging, reliable delivery, store and forward.
Posted by "Thomas R. Corbin" <th...@gmail.com>.
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.
Re: Not quite sure where to go next - network bridging, reliable
delivery, store and forward.
Posted by Joe Fernandez <jo...@ttmsolutions.com>.
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.
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.
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.
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.
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.
>>
>> /*
>> * $$
>> *
>>
>> ***************************************************************************
>> *
>> * Copyright (c) 2006 Coned. All rights reserved.
>> *
>> * Company: http://www.coned.com
>> *
>>
>> ***************************************************************************
>> */
>> package com.coned.util.db;
>>
>>
>> import java.net.URI;
>> import javax.sql.DataSource
>>
>> import org.apache.activemq.broker.BrokerService
>> import org.apache.activemq.network.NetworkConnector
>> import org.apache.activemq.network.DiscoveryNetworkConnector
>> import org.apache.activemq.broker.jmx.ManagementContext
>> import org.apache.activemq.store.journal.JournalPersistenceAdapterFactory
>> import org.apache.activemq.broker.view.ConnectionDotFilePlugin
>> import org.apache.activemq.broker.view.DestinationDotFilePlugin
>>
>> import org.apache.derby.jdbc.EmbeddedDataSource
>>
>> import org.apache.log4j.Logger;
>>
>> import com.samsix.util.LoggerControl
>> import com.samsix.util.HostNameProvider
>>
>>
>>
>> /**
>> * Utility to create the jms broker.
>> */
>> public class JmsBroker
>> {
>> private static final Logger logger = Logger.getLogger( JmsBroker );
>>
>>
>> String applicationNickname;
>> String transportConnectorUri;
>> String networkConnectorUri;
>> DataSource dataSource
>>
>>
>> public void createBroker()
>> {
>> turnOnActiveMqLogging()
>>
>> BrokerService broker = new BrokerService();
>>
>> // configure the broker
>> broker.brokerName = getBrokerName()
>> broker.useJmx = true;
>> broker.dataDirectory = getDataDirectory()
>>
>> //
>> // Suggested via email. Also see:
>> //
>> //
>> http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/NetworkLoadTest.java?view=markup
>> //
>> broker.getManagementContext().setCreateConnector( false );
>>
>> //logger.error "data directory: ${getDataDirectory()}"
>>
>> addPlugins( broker )
>> addNetworkConnector( broker )
>> addManagementContext( broker )
>> addPersistenceAdaptor( broker )
>>
>> broker.addConnector( transportConnectorUri );
>> broker.start();
>> }
>>
>>
>> def addPersistenceAdaptor( broker )
>> {
>> EmbeddedDataSource dataSource = new
>> EmbeddedDataSource()
>> JournalPersistenceAdapterFactory factory = new
>> JournalPersistenceAdapterFactory()
>>
>> dataSource.databaseName = getDataDirectory() + File.separator
>> + "derbydb"
>> dataSource.createDatabase = "create"
>> factory.journalLogFiles = 5
>> factory.dataDirectory = getDataDirectory()
>> factory.dataSource = dataSource
>>
>> broker.persistenceFactory = factory
>> }
>>
>>
>> def addManagementContext( broker )
>> {
>> ManagementContext context = new ManagementContext()
>> context.useMBeanServer = true
>> context.createConnector = true
>> context.connectorPort = getJmxPort()
>> context.jmxDomainName = "org.apache.activemq"
>>
>> broker.managementContext = context
>> }
>>
>>
>> def addNetworkConnector( broker )
>> {
>> // NetworkConnector connector = broker.addNetworkConnector(
>> networkConnectorUri );
>>
>> NetworkConnector connector = new DiscoveryNetworkConnector( new
>> URI( networkConnectorUri ) )
>> connector.name = "masterJms"
>> connector.duplex = true
>> connector.dynamicOnly = false
>>
>> //
>> // just read something from james strachan...
>> // "For demand forwarding I think you need to set
>> <networkConnector conduitSubscriptions="false" ..."
>> //
>> //
>> https://issues.apache.org/activemq/browse/AMQ-632;jsessionid=2E616BDE6A9E07FF60967D5A69352D1F?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> //
>> connector.conduitSubscriptions = true
>>
>>
>> connector.bridgeTempDestinations = true
>> connector.decreaseNetworkConsumerPriority = false
>>
>> //
>> // networkTTL (defaults to 1)
>> //
>> // the number of brokers in the network that messages
>> // and subscriptions can pass through
>> //
>> //
>> connector.networkTTL = 100
>>
>> broker.addNetworkConnector( connector )
>> }
>>
>>
>> def addPlugins( broker )
>> {
>> def plugins = []
>> def connectionDotPlugin = new ConnectionDotFilePlugin()
>> def destinationDotPlugin = new DestinationDotFilePlugin()
>>
>> connectionDotPlugin.file =
>> "${getDataDirectory()}${File.separator}${getBrokerName()}-Connection.dot"
>> destinationDotPlugin.file =
>> "${getDataDirectory()}${File.separator}${getBrokerName()}-Destination.dot"
>>
>> // plugins << connectionDotPlugin
>> plugins << destinationDotPlugin
>>
>> broker.plugins = plugins
>> }
>>
>>
>> String getDataDirectory()
>> {
>>
>> "${System.properties.'java.io.tmpdir'}${File.separator}activemq${File.separator}${applicationNickname}"
>> }
>>
>>
>> def turnOnActiveMqLogging()
>> {
>> def loggerControl = new LoggerControl()
>> loggerControl.setDebug( "org.apache.activemq" )
>> loggerControl.afterPropertiesSet()
>> }
>>
>>
>> int getJmxPort()
>> {
>> def tmp = transportConnectorUri.substring(
>> transportConnectorUri.lastIndexOf( ":" ) + 1 )
>> // println "tmp - transport port#: [${tmp}]"
>>
>> Integer.parseInt( tmp.trim() ) + 100
>> }
>>
>>
>> String getBrokerName()
>> {
>> "${new HostNameProvider().get()}-${applicationNickname}"
>> }
>>
>>
>> String getClientId( String topicName )
>> {
>> "${new
>> HostNameProvider().get()}-${applicationNickname}-${topicName}"
>> }
>>
>>
>> String getBrokerUri()
>> {
>> "vm://${getBrokerName()}"
>> }
>> }
>>
>>
>>
>
>
--
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.-tp19764204p19766179.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Not quite sure where to go next - network bridging, reliable
delivery, store and forward.
Posted by Joe Fernandez <jo...@ttmsolutions.com>.
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.
>
> /*
> * $$
> *
>
> ***************************************************************************
> *
> * Copyright (c) 2006 Coned. All rights reserved.
> *
> * Company: http://www.coned.com
> *
>
> ***************************************************************************
> */
> package com.coned.util.db;
>
>
> import java.net.URI;
> import javax.sql.DataSource
>
> import org.apache.activemq.broker.BrokerService
> import org.apache.activemq.network.NetworkConnector
> import org.apache.activemq.network.DiscoveryNetworkConnector
> import org.apache.activemq.broker.jmx.ManagementContext
> import org.apache.activemq.store.journal.JournalPersistenceAdapterFactory
> import org.apache.activemq.broker.view.ConnectionDotFilePlugin
> import org.apache.activemq.broker.view.DestinationDotFilePlugin
>
> import org.apache.derby.jdbc.EmbeddedDataSource
>
> import org.apache.log4j.Logger;
>
> import com.samsix.util.LoggerControl
> import com.samsix.util.HostNameProvider
>
>
>
> /**
> * Utility to create the jms broker.
> */
> public class JmsBroker
> {
> private static final Logger logger = Logger.getLogger( JmsBroker );
>
>
> String applicationNickname;
> String transportConnectorUri;
> String networkConnectorUri;
> DataSource dataSource
>
>
> public void createBroker()
> {
> turnOnActiveMqLogging()
>
> BrokerService broker = new BrokerService();
>
> // configure the broker
> broker.brokerName = getBrokerName()
> broker.useJmx = true;
> broker.dataDirectory = getDataDirectory()
>
> //
> // Suggested via email. Also see:
> //
> //
> http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/NetworkLoadTest.java?view=markup
> //
> broker.getManagementContext().setCreateConnector( false );
>
> //logger.error "data directory: ${getDataDirectory()}"
>
> addPlugins( broker )
> addNetworkConnector( broker )
> addManagementContext( broker )
> addPersistenceAdaptor( broker )
>
> broker.addConnector( transportConnectorUri );
> broker.start();
> }
>
>
> def addPersistenceAdaptor( broker )
> {
> EmbeddedDataSource dataSource = new
> EmbeddedDataSource()
> JournalPersistenceAdapterFactory factory = new
> JournalPersistenceAdapterFactory()
>
> dataSource.databaseName = getDataDirectory() + File.separator
> + "derbydb"
> dataSource.createDatabase = "create"
> factory.journalLogFiles = 5
> factory.dataDirectory = getDataDirectory()
> factory.dataSource = dataSource
>
> broker.persistenceFactory = factory
> }
>
>
> def addManagementContext( broker )
> {
> ManagementContext context = new ManagementContext()
> context.useMBeanServer = true
> context.createConnector = true
> context.connectorPort = getJmxPort()
> context.jmxDomainName = "org.apache.activemq"
>
> broker.managementContext = context
> }
>
>
> def addNetworkConnector( broker )
> {
> // NetworkConnector connector = broker.addNetworkConnector(
> networkConnectorUri );
>
> NetworkConnector connector = new DiscoveryNetworkConnector( new
> URI( networkConnectorUri ) )
> connector.name = "masterJms"
> connector.duplex = true
> connector.dynamicOnly = false
>
> //
> // just read something from james strachan...
> // "For demand forwarding I think you need to set
> <networkConnector conduitSubscriptions="false" ..."
> //
> //
> https://issues.apache.org/activemq/browse/AMQ-632;jsessionid=2E616BDE6A9E07FF60967D5A69352D1F?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> //
> connector.conduitSubscriptions = true
>
>
> connector.bridgeTempDestinations = true
> connector.decreaseNetworkConsumerPriority = false
>
> //
> // networkTTL (defaults to 1)
> //
> // the number of brokers in the network that messages
> // and subscriptions can pass through
> //
> //
> connector.networkTTL = 100
>
> broker.addNetworkConnector( connector )
> }
>
>
> def addPlugins( broker )
> {
> def plugins = []
> def connectionDotPlugin = new ConnectionDotFilePlugin()
> def destinationDotPlugin = new DestinationDotFilePlugin()
>
> connectionDotPlugin.file =
> "${getDataDirectory()}${File.separator}${getBrokerName()}-Connection.dot"
> destinationDotPlugin.file =
> "${getDataDirectory()}${File.separator}${getBrokerName()}-Destination.dot"
>
> // plugins << connectionDotPlugin
> plugins << destinationDotPlugin
>
> broker.plugins = plugins
> }
>
>
> String getDataDirectory()
> {
>
> "${System.properties.'java.io.tmpdir'}${File.separator}activemq${File.separator}${applicationNickname}"
> }
>
>
> def turnOnActiveMqLogging()
> {
> def loggerControl = new LoggerControl()
> loggerControl.setDebug( "org.apache.activemq" )
> loggerControl.afterPropertiesSet()
> }
>
>
> int getJmxPort()
> {
> def tmp = transportConnectorUri.substring(
> transportConnectorUri.lastIndexOf( ":" ) + 1 )
> // println "tmp - transport port#: [${tmp}]"
>
> Integer.parseInt( tmp.trim() ) + 100
> }
>
>
> String getBrokerName()
> {
> "${new HostNameProvider().get()}-${applicationNickname}"
> }
>
>
> String getClientId( String topicName )
> {
> "${new
> HostNameProvider().get()}-${applicationNickname}-${topicName}"
> }
>
>
> String getBrokerUri()
> {
> "vm://${getBrokerName()}"
> }
> }
>
>
>
--
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.-tp19764204p19765870.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.