cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Question about JMS Session Pool
Date Wed, 03 Sep 2008 16:03:54 GMT
The Spring JMS layer contains two parts: the JmsTemplate which can be
used to send / consume messages, and the MessageListenerContainers
that can be used to consumer messages more efficiently.  Caching is
configurable on the DefaultMessageListenerContainer, but the
JmsTemplate doesn't do caching, mainly because it is meant to work in
a Java EE environment, where the client is supposed to create a
connection / session / sender every time.  Thus, a really good thing
is to configure a JMS pooled connection factory underneath (see
http://activemq.apache.org/spring-support.html).

On Wed, Sep 3, 2008 at 4:53 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
> Actually, one more note:
>
> He STRONGLY suggests not writing any JMS code in the JMS transport at all:
>
> <jstrachan> dkulp: don't even think of writing any JMS code within cxf, just
> use spring message listener container
> <jstrachan> you can configure the spring JMS stuff however you want
> <jstrachan> we use URIs in camel for example
> <jstrachan> seriously, delete your jms code, just use spring however you wanna
> use it
>
>
> I don't know all the details about it, but apparently if you use the Spring
> jms/messaging stuff, it will work with the Spring transactions and security
> and such which doesn't work with "pure jms" stuff.   One reason we've seen
> for not using our JMS and instead using Camel or Mule or similar is due to
> the lack of spring transaction support.  It might be a good idea to grab the
> Camel and/or ServiceMix JMS code (probably Camel) and use that as more of a
> starting point.
>
> Also, the latest public draft of the SOAP/JMS stuff is at:
> http://www.w3.org/TR/2008/WD-soapjms-20080723/
>
>
> Dan
>
>
>
> On Wednesday 03 September 2008 10:23:42 am Daniel Kulp wrote:
>> I just asked James Strachan and he said:
>>
>> <jstrachan> dkulp: but yes, you've gotta cache sessions
>> <jstrachan> and consumers
>>
>> I don't know the details, but since he knows the insides of ActiveMQ pretty
>> well, I'd take his advise.   :-)
>>
>> Dan
>>
>> On Tuesday 02 September 2008 5:00:38 pm Christian Schneider wrote:
>> > Hi,
>> >
>> > I am just working an a refactoring of the JMS Transport. In the module
>> > there is an implementation of a session cache.
>> >
>> > As we later want to switch to SpringTemplate and Spring
>> > ListenerContainer I want to get rid of as much pooling implementation as
>> > possible.
>> > So my question is: Do we really need a session cache. As far as I
>> > understood from JMS specs sessions are lightweight short lived objects.
>> > So I think it would not harm to create a new session for each message
>> > and destroy it later. The same is true for producers.
>> >
>> > The connection on the other hand has to be cached as it is costly to
>> > create. I think the connection could be stored as a simple attribute of
>> > JMSConduit or JMSDestination.
>> > As far as I know it is thread safe too.
>> >
>> > What is your knowledge about this?
>> >
>> > Best regards
>> >
>> > Christian
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Mime
View raw message