You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@camel.apache.org by northface01 <no...@gmail.com> on 2012/08/08 17:03:59 UTC

SJMS Issues

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
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.

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: http://camel.465427.n5.nabble.com/SJMS-Issues-tp5716996.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: SJMS Issues

Posted by Scott England-Sullivan <su...@gmail.com>.

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 <no...@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 <
> 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 <no...@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
> >
>



-- 
-- 
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768

Re: SJMS Issues

Posted by Gary Liu <no...@gmail.com>.

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 <no...@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
>

Re: SJMS Issues

Posted by Christian Müller <ch...@gmail.com>.

Good work Scott! Keep it up...

Best,
Christian

On Wed, Aug 8, 2012 at 6:35 PM, Scott England-Sullivan
<su...@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 <no...@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
>



--

Re: SJMS Issues

Posted by Scott England-Sullivan <su...@gmail.com>.

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 <no...@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