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

EasternWahoo commented on CXF-6199:
-----------------------------------

The fix works, and supports multiple JMS consumers.  Does that mean the 
deprecated JmsConfiguration style should be used, as documented here 
http://cxf.apache.org/docs/jms-transport.html?  Here's my config:
        <bean id="jmsConfighello" 
class="org.apache.cxf.transport.jms.JMSConfiguration"
                p:connectionFactory-ref="jmsConnectionFactory"
                p:targetDestination="test.cxf.jmstransport.queue"               
                
                p:concurrentConsumers="5"                       
                />
        <jaxws:endpoint xmlns:tns="http://service.soapjms.sandbox.com/";
                id="helloJms" address="jms:queue:test.cxf.jmstransport.queue"
                implementor="..." publish="true"
                wsdlLocation="wsdl/hello.wsdl"  >
                <jaxws:features>                        
                        <bean class="org.apache.cxf.feature.LoggingFeature" />  
                                 
                        <bean 
class="org.apache.cxf.transport.jms.JMSConfigFeature"
                                p:jmsConfig-ref="jmsConfig-hello"
                                />                      
                </jaxws:features>       
        </jaxws:endpoint>

> 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)

Reply via email to