[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] Commented: (AMQ-816) new transport for load balancing client
From:       "James Strachan (JIRA)" <jira () apache ! org>
Date:       2008-09-29 14:31:01
Message-ID: 1657510564.1222698661589.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/activemq/browse/AMQ-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46056#action_46056 \
] 

James Strachan commented on AMQ-816:
------------------------------------

Daniel: the jedi transport is different to the store and forward networks. Store and \
forward networks are designed to forward subscription information across a network of \
brokers - to do exactly what you describe. So just using a [store and foward \
network|http://activemq.apache.org/networks-of-brokers.html] should do the trick for \
your requirement.

The jedi transport is an alternative to broker store-forward networks; where brokers \
don't know anything about each other - and the clients do all the work. e.g. \
producers send to any available broker and the consumers consume from all the brokers \
silently under the covers. Over time this could get clever, load balancing traffic \
over destinations evenly - or partitioning destinations to different brokers etc




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


[prev in list] [next in list] [prev in thread] [next in thread]