[
https://issues.apache.org/activemq/browse/AMQ-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43517#action_43517
]
Daniel Rodrigues commented on AMQ-816:
--------------------------------------
Hi,
would this include also tackling the problem that having a persistent consumer
on one broker he won't be forwarded the messages that were persisted in some
other?
I am thinking about the following case: we have a network of brokers, say
brokerA and brokerB. A consumer subscribes with a unique id
client1:subscription1 to brokerB. Therefore, if offline, messages will be
persisted on brokerB. After a while, brokerB goes down, and the same consumer
fails over to brokerA. He's able to receive all new messages, but will not
receive persisted messages when brokerB comes back to life.
What I would like to see is basically a consumer be recognized as unique over
an entire network of brokers and not just on one broker, so messages persisted
in one broker could also be forwarded whenever a durable subscription would
appear somewhere else on the network.
Thank you!
daniel
> new transport for load balancing client requests across many brokers
> --------------------------------------------------------------------
>
> Key: AMQ-816
> URL: https://issues.apache.org/activemq/browse/AMQ-816
> Project: ActiveMQ
> Issue Type: Improvement
> Reporter: James Strachan
> Assignee: Rob Davies
> Fix For: 5.2.0
>
>
> Rather than creating store and forward networks, it might be nice to have a
> kind of composite transport where...
> * consumers are created on each broker found/discovered. This allows messages
> to be sent to any broker and consumed by any consumer
> * producers could dynmically choose which broker to send a message to (or
> could just pick one broker per session/producer)
> this allows for a load balancing layer at the client side which avoids the
> need for store/forward networks (which results in more network traffic and
> often increases load on the brokers).
> So it basically pushes load back to the clients. The downside of this appoach
> is that the clients have more connections to brokers - but given the linear
> scalability of this, it sounds a great idea to me at least :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
