camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott England-Sullivan <>
Subject Re: SJMS Issues
Date Wed, 08 Aug 2012 16:35:14 GMT
Hi and thanks for the feedback.  I have put comments inline with your notes

On Wed, Aug 8, 2012 at 11:03 AM, northface01 <> 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&amp;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
> 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:
> Sent from the Camel Development mailing list archive at

Scott England-Sullivan
Twitter: sully6768

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message