Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 46293 invoked from network); 3 Sep 2008 14:54:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Sep 2008 14:54:01 -0000 Received: (qmail 15835 invoked by uid 500); 3 Sep 2008 14:53:58 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 15795 invoked by uid 500); 3 Sep 2008 14:53:58 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 15782 invoked by uid 99); 3 Sep 2008 14:53:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 07:53:58 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.79.199.57] (HELO server.dankulp.com) (64.79.199.57) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 14:52:58 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 05BC5197C28E; Wed, 3 Sep 2008 10:53:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.m93Sa7AtYQ Received: from [192.168.1.102] (c-24-147-10-180.hsd1.ma.comcast.net [24.147.10.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTP id 86DFC197C0BD; Wed, 3 Sep 2008 10:53:26 -0400 (EDT) From: Daniel Kulp To: dev@cxf.apache.org Subject: Re: Question about JMS Session Pool Date: Wed, 3 Sep 2008 10:53:26 -0400 User-Agent: KMail/1.9.9 Cc: Christian Schneider References: <48BDA976.4030707@die-schneider.net> <200809031023.42917.dkulp@apache.org> In-Reply-To: <200809031023.42917.dkulp@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809031053.26245.dkulp@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=0.3 required=3.0 tests=BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.4 Actually, one more note: He STRONGLY suggests not writing any JMS code in the JMS transport at all: dkulp: don't even think of writing any JMS code within cxf, just use spring message listener container you can configure the spring JMS stuff however you want we use URIs in camel for example 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: > > dkulp: but yes, you've gotta cache sessions > 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