activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
Date Mon, 29 Sep 2008 14:31:01 GMT

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


Mime
View raw message