Hi all,
I am currently rewriting the CXF jms transport to get rid of spring jms.
So two parts that I needed to replace are the JmsTemplate and the
DefaultMessageListenerContainer.
So the question is which features of these should I recreate and which
are not necessary. Some more concrete questions below:
Lets first look at the sender side. I am currently working with a single
connection per CXF conduit and open sessions on it per thread.
On the receiving side I use either consumer.receive() or a message
listener depending if the incoming CXF call is synchronous or asynchronous.
1. Will it make sense to use more than one connection in parallel? ( I
observed that all sessions seem to be synchronized when activemq sends
the data. On the other hand it all has to go through the one network
anyway).
Using several connections is problematic in the case of a temporary
reply queue as I have to make sure the queue is created by the same
connection that then sends and receives on it. I could use one temp
queue per connection of course but this would make the code a lot more
complicated.
2. Is there a difference performance wise between consumer.receive and a
message listener?
3. I use a messageSelector for correlation. How much does this impact
performance?
The next one is the server side.
DefaultMessageListenerContainer uses several consumers in parallel in
addition to a ExecutorService to then parallelize the calls to the
MessageListener.
It also seems to spawn one thread per consumer where it polls using
consumer.receive().
1. I currently use one connection and one consumer and only after that
parallelize using an ExecutorService. Should I use more than one
consumer and or more than one connection ?
If anyone wants to look at the current sources. They can be found in the
trunk of cxf. For convenience look here:
https://github.com/apache/cxf/tree/trunk/rt/transports/jms
I would be happy about any feedback regarding the implementation.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
