Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <263990049.1213697700457.JavaMail.jira@brutus>
Date: Tue, 17 Jun 2008 03:15:00 -0700 (PDT)
From: "Daniel Rodrigues (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-816) new transport for load balancing client
 requests across many brokers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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