Return-Path: X-Original-To: apmail-camel-issues-archive@minotaur.apache.org Delivered-To: apmail-camel-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4225E17413 for ; Mon, 3 Nov 2014 21:32:35 +0000 (UTC) Received: (qmail 3612 invoked by uid 500); 3 Nov 2014 21:32:34 -0000 Delivered-To: apmail-camel-issues-archive@camel.apache.org Received: (qmail 3485 invoked by uid 500); 3 Nov 2014 21:32:34 -0000 Mailing-List: contact issues-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list issues@camel.apache.org Received: (qmail 3341 invoked by uid 99); 3 Nov 2014 21:32:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Nov 2014 21:32:34 +0000 Date: Mon, 3 Nov 2014 21:32:34 +0000 (UTC) From: "Aaron Whiteside (JIRA)" To: issues@camel.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (CAMEL-7994) SJMSComponent effectively ignores setConnectionCount() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Aaron Whiteside created CAMEL-7994: -------------------------------------- Summary: SJMSComponent effectively ignores setConnectionCount() Key: CAMEL-7994 URL: https://issues.apache.org/jira/browse/CAMEL-7994 Project: Camel Issue Type: Bug Components: camel-sjms Affects Versions: 2.14.0 Reporter: Aaron Whiteside SJMSComponent effectively ignores setConnectionCount() This is because the JmsProducer, by default, pre-populates sessions+producers on Producer.doStart(), which is called by the CamelContext in a single thread and the way the ConnectionFactoryResource is configured, it returns the most recently idle connection (So really it always returns the first connection opened). This patch attached makes the ConnectionFactoryResource effectively return connections in a round-robbin. Unit test attached in included. This is important because TCP has a certain overhead per socket which makes it impossible to achieve much more than 6~ messages a second, regardless of the CPU and IO resources available to a broker. To fully utilize a broker multiple connections must be opened. This is also important if your ConnectionFactory represent a cluster (Like in the case of HornetQ), where subsequent connections are balanced across nodes in the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)