camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Liu <northfac...@gmail.com>
Subject Re: SJMS Issues
Date Thu, 09 Aug 2012 02:39:13 GMT
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 <sully6768@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 <northface01@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&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
> > 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
>

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