You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Robert Kuipers (JIRA)" <ji...@apache.org> on 2015/01/16 11:03:34 UTC

[jira] [Commented] (CXF-6199) Allow scalability for slow services on jms

    [ https://issues.apache.org/jira/browse/CXF-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280045#comment-14280045 ] 

Robert Kuipers commented on CXF-6199:
-------------------------------------

Link to the post on the mailing list that resulted in this issue being created: http://cxf.547215.n5.nabble.com/CXF-3-0-1-doesn-t-have-concurrentConsumers-td5749534.html#a5753084

For a couple of our customers, it is a requirement to be able to change the number of consumers based on a configuration setting per porttype (this was possible with CXF 2.7.x), in order to allocate resources to queues that required a high throughput. Is this possible with both options?

> Allow scalability for slow services on jms
> ------------------------------------------
>
>                 Key: CXF-6199
>                 URL: https://issues.apache.org/jira/browse/CXF-6199
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 3.0.3
>            Reporter: Christian Schneider
>            Assignee: Christian Schneider
>             Fix For: 3.1.0
>
>
> Currently the CXF transport does not scale well if the service implementation is slow.
> We need a facility to work with several threads.
> There are two options for this:
> 1. Allow to use more than one consumer
> 2. Use an executor in JMSDestination.onMessage
> Option 1 works well with PollingMessageListener but not with the event driven MessageListener. It is also depending on the JMS provider how it scales with number of consumers.
> Option 2 works in all cases but does not allow to profit from more than one consumer if the provider is slow with a single consumer.
> So probably we will need both variants.



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