Return-Path: 
 <users-return-55406-apmail-camel-users-archive=camel.apache.org@camel.apache.org>
X-Original-To: apmail-camel-users-archive@www.apache.org
Delivered-To: apmail-camel-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 382831782F
	for <apmail-camel-users-archive@www.apache.org>;
 Fri, 22 May 2015 04:02:43 +0000 (UTC)
Received: (qmail 88574 invoked by uid 500); 22 May 2015 04:02:41 -0000
Delivered-To: apmail-camel-users-archive@camel.apache.org
Received: (qmail 88416 invoked by uid 500); 22 May 2015 04:02:41 -0000
Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@camel.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@camel.apache.org>
List-Post: <mailto:users@camel.apache.org>
List-Id: <users.camel.apache.org>
Reply-To: users@camel.apache.org
Delivered-To: mailing list users@camel.apache.org
Received: (qmail 88405 invoked by uid 99); 22 May 2015 04:02:41 -0000
Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 May 2015 04:02:41 +0000
Received: from localhost (localhost [127.0.0.1])
	by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org)
 with ESMTP id 154CAC7683
	for <users@camel.apache.org>; Fri, 22 May 2015 04:02:41 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: 2.314
X-Spam-Level: **
X-Spam-Status: No, score=2.314 tagged_above=-999 required=6.31
	tests=[KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001, URI_HEX=1.313]
	autolearn=disabled
Received: from mx1-us-west.apache.org ([10.40.0.8])
	by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new,
 port 10024)
	with ESMTP id rvAelScevhvF for <users@camel.apache.org>;
	Fri, 22 May 2015 04:02:32 +0000 (UTC)
Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15])
	by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with
 ESMTP id E1073204F2
	for <users@camel.apache.org>; Fri, 22 May 2015 04:02:31 +0000 (UTC)
Received: from msam.nabble.com (unknown [162.253.133.85])
	by mbob.nabble.com (Postfix) with ESMTP id 86068D5A664
	for <users@camel.apache.org>; Thu, 21 May 2015 21:02:01 -0700 (PDT)
Date: Thu, 21 May 2015 21:02:01 -0700 (MST)
From: apara <apara@standardset.com>
To: users@camel.apache.org
Message-ID: <1432267321185-5767406.post@n5.nabble.com>
In-Reply-To: <1432238489505-5767401.post@n5.nabble.com>
References: <1432238489505-5767401.post@n5.nabble.com>
Subject: Re: LoadBalancer seems to be doing some sort of throttling
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

So, it turns out that the processing of simple expressions is apparently
somewhat slow (my camel routes are currently handling 2300 events/second) so
each message is taking milliseconds to get through the pipelines.  If the
load balancing calculation takes too long it cannot keep the pipelines full.

I replaced the sticky(...) specification with my own code and things are
flying:

        .loadBalance(
            new QueueLoadBalancer() {
                @Override
                protected Processor chooseProcessor(final List<Processor>
processors, final Exchange exchange) {
                    //Get the partition key
                    //
                    final String
                        partitionKey =
                            exchange
                                .getIn()
                                .getBody(
                                    EventData.class
                                )
                                .getPartitionKey();

                    //Calculate the position
                    //
                    final int
                        size = processors.size(),
                        index = (partitionKey.hashCode() % size + size) %
size;

                    //Return the processor to use
                    //
                    return
                        processors
                            .get(
                                index
                            );
                }
            }
        )

It's amazing the kind of issues you start to find at these processing
speeds.  I am quite satisfied with Camel's raw processing speed when it
comes to core message routing.

-AP_




--
View this message in context: http://camel.465427.n5.nabble.com/LoadBalancer-seems-to-be-doing-some-sort-of-throttling-tp5767401p5767406.html
Sent from the Camel - Users mailing list archive at Nabble.com.