Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <1526432435.1234893059421.JavaMail.jira@brutus>
Date: Tue, 17 Feb 2009 09:50:59 -0800 (PST)
From: "Eric (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-1932) Weak scalability in network of brokers
 (subsrciption shows quadratic order)
In-Reply-To: <1673094818.1221058252605.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/AMQ-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49723#action_49723 ] 

Eric commented on AMQ-1932:
---------------------------

For a Huge Project (500 to 1000 servers on 2 different sites), I want to have the same "embedded broker & network of broker" configuration on each node and be able to dynamically add or substract a "standard" server in the network.

This problem seems important for me in a multi site distribution, where WAN networks are relatively slow.

Eric

> Weak scalability in network of brokers (subsrciption shows quadratic order)
> ---------------------------------------------------------------------------
>
>                 Key: AMQ-1932
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1932
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 5.1.0
>         Environment: Linux 2.6.25, Java 1.6.0._07
>            Reporter: Martin Cornelius
>
> In a network of brokers, any subscription to a topic causes a network load that is related to the number of brokers with quadratic order.
> On subscription to a topic, the broker where the subscription is done sends a control-message to all other brokers. Every broker reacts on this control-message by sending another control-message to all other brokers. The same happens on every unsubscribing from a topic. This implies, that the network load caused by a (un)subscription is governed by the term N*N, what kills scalability.
> Interestingly, when subscribing to a queue, (as opposed to a topic) this 'evil' behaviour is observed only on the very first subscription to the queue.(i suppose when the queue is 'unknown' to the brokers)  All subsequent subscriptions to a queue that has been subscribed to before by any client show only linear order, means: The broker where the subscription is made sends a control-message to all other brokers, but this does NOT trigger subsequent messages. Also, unsubscription from a topic always behaves the latter way.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.