Before my fix for the issue
https://issues.apache.org/jira/browse/CXF-6199 there were two different
approaches on server side.
If there was an XA transactionManager then the
PollingMessageListenerContainer was use if not then the event driven
MessageListenerContainer was used.
After the fix now only PollingMessageListenerContainer is used.
The PollingMessageListenerContainer runs polling threads. So the
behaviour depends on the number of threads. Before the fix there was
only one thread. Now
you can configure the number of threads. Each thread starts a consumer.
There may be still a performance problem here as the session and
consumer are always recreated after each message. The reason is that it
makes handling of connection problems easier.
I will check if this can be improved.
The MessageListenerContainer registers a MessageLstener and leaves the
thread handling to the provider. Unfortunately this did not scale well
at least for ActiveMQ.
So I do not use it anymore.
Christian
On 16.01.2015 13:45, André Costa Lima wrote:
Hi,
I have a question regarding this subject. When my web services are invoked
on server side, I see that they run in an ActiveMQ thread. I guess that
each thread is created from an Executor. Does not this support concurrency
on the server side automatically?
André Costa Lima
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
