Hi Gary, NP on getting them in. Willem has been kind enough to commit my fixes for me. I will send out a response when they are added.
Regarding the client ack, would the ability to batch transactions alleviate your concerns about performance? On Wed, Aug 8, 2012 at 10:39 PM, Gary Liu <northfac...@gmail.com> wrote: > Hi Scott, > > Please make sure the fixes will be included in the SJMS component for Camel > 2.11.0 release. Right now I am using my locally built SJMS jar but > eventually I would like to have it as a dependency of my maven project. > > Also please do try to support the CLIENT_ACKNOWLEDGE acknowledgement mode > in the near future. I think there are many real world applications that > would desire such support so that messages that fail to be processed by JMS > clients should remain in the queue or durable subscription in the broker. > The SESSION_TRANSACTED mode meets this requirement but has worse > performance. > > Thanks, > Gary > > On Wed, Aug 8, 2012 at 12:35 PM, Scott England-Sullivan < > sully6...@gmail.com > > wrote: > > > Hi and thanks for the feedback. I have put comments inline with your > notes > > below. > > > > > > On Wed, Aug 8, 2012 at 11:03 AM, northface01 <northfac...@gmail.com> > > wrote: > > > > > I am not sure if the below issues have been addressed. But I found them > > in > > > the SJMS source code (f103b8b) I downloaded and I had to fix them in my > > > local build to make it work. > > > > > > 1) SjmsEndpoint.getDestinationName() should return a clean destination > > name > > > that just contains the quque/topic name. However it returns queue/topic > > > name > > > plus all parameters which causes the JMS provider I use to fail to > create > > > the consumer due to the additional > "?param1=value1&param2=value2..." > > > text in the destination name. > > > > > > > I see the error. I will roll it into a new update. > > > > > > > 2) In DefaultConsumer.MessageConsumerPool.destroyObject() method, the > > > model.getMessageConsumer().setMessageListener(null) call causes > > exceptions > > > since the messageListener in MessageConsumer is final for the JMS > > provider > > > I > > > use. I think this call is unnecessary and should be removed. Also I > think > > > SJMS could borrow the close methods in > > > org.springframework.jms.support.JmsUtils whose interfaces are defined > in > > > terms of standard JMS API and use them in various implementations of > the > > > ObjectPool.destroyObject() method. > > > > > > > Good suggestion. I will take a look at it. > > > > > > > > > > 3) DefaultConnectionResource does support setting the JMS clientId > using > > > the > > > connectionId property but this connectionId/clientId property is not > > > exposed > > > as a SjmeComponent/SjmeEndpoint property so the end user can't really > set > > > the JMS clientId. > > > > > > > This has been fixed in the latest update. There is a new > > ConnectionFactoryResource (was DefaultConnectionResource) that contains > the > > setter for the "clientId". > > > > > > > 4) The CLIENT_ACKNOWLEDGE SessionAcknowledgementType doesn't work. > When I > > > use this acknowledgementMode, all messages that have been successfully > > > processed by Camel routes stay in the queue afterwards. At least it > > should > > > work in the same fashion as camel-jms component where processed > messages > > > should only stay in the queue if unhandled exceptions are thrown during > > > processing by camel. > > > > > > > WIKI has been updated. CLIENT_ACKNOWLEDGE is not supported at this time. > > I don't have a strong set of use cases yet for its use so it has been > > difficult for me to find the correct home for a client acknowledgement > > strategy. It is on the radar though. > > > > > > > > > > > > > -- > > > View this message in context: > > > http://camel.465427.n5.nabble.com/SJMS-Issues-tp5716996.html > > > Sent from the Camel Development mailing list archive at Nabble.com. > > > > > > > > > > > -- > > -- > > Scott England-Sullivan > > ---------------------------------- > > FuseSource > > Web: http://www.fusesource.com > > Blog: http://sully6768.blogspot.com > > Twitter: sully6768 > > > -- -- Scott England-Sullivan ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://sully6768.blogspot.com Twitter: sully6768
