camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From northface01 <>
Subject SJMS Issues
Date Wed, 08 Aug 2012 15:03:59 GMT
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.

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.

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.

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.

View this message in context:
Sent from the Camel Development mailing list archive at

View raw message