James Strachan schrieb:
According to the JMS spec a session is a short lived object that should not
cause any harm when being created every time.
Where did you read that BTW? :)
This was what I had remembered from the jms spec. I just reread the
chapter ... It says a session is a lightweight object.
I guess I had interpreted this into it ;-) So I must correct myself.
It was about a year ago :) We use Springs MessageListenerContainer for
consuming and JmsTemplate for sending in Camel - we always have.
I just looked into the source. So you are also using a
MessageListenerContainer for request / reply. When I wrote the CXF jms
code I tried to figure out how you do this but did not
understand the concept of the future holder. Now that I have written
something similar I finally understood it ;-)
The main issue with the Spring abstractions is for sending; unless you
are using a JMS pool of some kind, the producer is gonna be very
inefficient and network chatty. e.g. 3 RMI calls to do a single send
(create producer, send message, close producer) :)
Hmm ... do you have any idea how to cope with that? Are there best
practices for the different jms providers which pooling
works best? I think there should be some informations for people who use
other jms providers than camel.
On the producer side I had no such
solution though. I did some load tests with the cxf implementation and had
no problems with ActiveMQ.
All in all I think it is not so good that camel uses a special component for
ActiveMQ as the problem is existent for every jms provider and should be
solved in a general way.
The general solution is to configure things correctly - so use
whatever JMS pool is most appropriate to your JMS provider. Since few
users ever even know what the right way to setup JMS connection
factories for use with Spring's JmsTemplate and
MessageListenerContainer classes we do it all for you for ActiveMQ in
the ActiveMQComponent - letting you just focus on the one thing you're
probably gonna want to configure - the brokerURL.
Indeed you don't even have to configure the ActiveMQComponent at all!
Just send to "activemq:SomeQueue" and it'll do the right thing for
most use cases with zero configuration!
There's no magic in the ActiveMQComponent - we're just following
convention over configuration so users don't have to cut and paste a 2
page blob of XML to be able to use Camel and ActiveMQ efficiently
together. You can easily do the same kind of thing with any other JMS
provider and the JMSComponent directly - it just takes more
configuration code.
Ok so if I understand you right it is only a configuration issue. I
always thought the activemq component would have a different codebase
from the jms component.
So I was quite reluctant to use it. Thanks for the clarification.
Btw. I just searched the activemq component in the camel sources and did
not find it. Is it not in the components directory?
Greetings
Christian
