cschneider wrote
> The 3.x implementation does not use spring anymore. So we do not have
> the spring implementations of MessageListenerContainer that worked with
> separate consumers and polling.
>
> If you look at
> org.apache.cxf.transport.jms.JMSDestination.createTargetDestinationListener()
> you see how the MessageListenerContainer we use now is created.
> If there is a transaction manager then we use the
> PollingMessageListenerContainer which uses one thread. If there is no
> transaction manager then we use a MessageListenerContainer based on a
> MessageListener.
>
> In my performance tests
> (http://liquid-reality.de/display/liquid/2014/03/28/Revisiting+JMS+performance.+Improvements+in+CXF+3.0.0)
>
> this worked at least as fast as the spring variant with several consumers.
> I only tested with ActiveMQ though so if you use a different provider
> you may see a different performance.
>
> So as a short answer you currently can not set the consumer threads. We
> could add this if there is need but currently I did not find a good
> reason. So I stayed with the simplest solution.
Concurrent and maxConsumers is a requirement for scalable services. Keep in
mind, throughput is impacted as much (or more) by service execution time as
by CXF framework overhead. If service execution takes 500 ms, and the
request arrival rate is 10 requests per second, requests will queue up, and
response time will elongate. We cannot go into production with CXF JMS
without a mechanism for configuring concurrency.
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-3-0-1-doesn-t-have-concurrentConsumers-tp5749534p5753084.html
Sent from the cxf-user mailing list archive at Nabble.com.
