You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Willem Jiang (JIRA)" <ji...@apache.org> on 2014/11/04 03:44:37 UTC

[jira] [Assigned] (CAMEL-7994) SJMSComponent effectively ignores setConnectionCount()

     [ https://issues.apache.org/jira/browse/CAMEL-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Willem Jiang reassigned CAMEL-7994:
-----------------------------------

    Assignee: Willem Jiang

> 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
>            Assignee: Willem Jiang
>         Attachments: round-robbin.patch
>
>
> 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). So all sessions being pre-populated by all SJMS endpoints always use the same single connection.
> This patch attached makes the ConnectionFactoryResource effectively return connections in a round-robbin manor. Unit test is included.
> This is important because TCP has a certain overhead per socket which makes it impossible to achieve much more than 6k~ 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 from the factory are balanced across nodes in the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)