You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by nmittal <nm...@rblt.com> on 2009/05/01 15:44:50 UTC
CMS and Multithreading
below is an excerpt from the book "ActiveMQ in action"...
The JMS spec specifically defines concurrency for various objects in the JMS
API and requires that only a few objects support concurrent access. The
ConnectionFactory, Connection and Destination objects are required to
support concurrent access while the Session, the MessageProducer and the
MessageConsumer objects do not support concurrent access. The point is that
the Session, the MessageProducer and the MessageConsumer objects should not
be shared across threads in a Java application.
However, the the examples that come with ActiveMQ CPP... the onMessage
function uses the session, consumer objects. I think the onMessage would be
called in seperate threads for each message in the queue. So given that
session and consumer classes are not threadsafe...is it correct to do so?
thanks
Nishant
--
View this message in context: http://www.nabble.com/CMS-and-Multithreading-tp23333314p23333314.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: CMS and Multithreading
Posted by nmittal <nm...@rblt.com>.
Thats awesome. saves a lot of time for me as a developer trying to do my own
synchronization.
thanks Tim.
Timothy Bish wrote:
>
> On Fri, 2009-05-01 at 06:44 -0700, nmittal wrote:
>> below is an excerpt from the book "ActiveMQ in action"...
>> The JMS spec specifically defines concurrency for various objects in the
>> JMS
>> API and requires that only a few objects support concurrent access. The
>> ConnectionFactory, Connection and Destination objects are required to
>> support concurrent access while the Session, the MessageProducer and the
>> MessageConsumer objects do not support concurrent access. The point is
>> that
>> the Session, the MessageProducer and the MessageConsumer objects should
>> not
>> be shared across threads in a Java application.
>>
>> However, the the examples that come with ActiveMQ CPP... the onMessage
>> function uses the session, consumer objects. I think the onMessage would
>> be
>> called in seperate threads for each message in the queue. So given that
>> session and consumer classes are not threadsafe...is it correct to do so?
>>
>> thanks
>> Nishant
>>
>
> While the spec defines that certain types be thread safe we've shrived
> to ensure that all operations on the CMS objects are thread safe. That
> being said I would advise showing constraint on overusing CMS objects in
> a method like onMessage as the time spent in that method delays delivery
> of messages, so you wouldn't want to start producing messages from
> onMessage for instance.
>
> Regards
> Tim.
>
> --
> Tim Bish
> http://fusesource.com
> http://timbish.blogspot.com/
>
>
>
>
>
--
View this message in context: http://www.nabble.com/CMS-and-Multithreading-tp23333314p23335072.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: CMS and Multithreading
Posted by Timothy Bish <ta...@gmail.com>.
On Fri, 2009-05-01 at 06:44 -0700, nmittal wrote:
> below is an excerpt from the book "ActiveMQ in action"...
> The JMS spec specifically defines concurrency for various objects in the JMS
> API and requires that only a few objects support concurrent access. The
> ConnectionFactory, Connection and Destination objects are required to
> support concurrent access while the Session, the MessageProducer and the
> MessageConsumer objects do not support concurrent access. The point is that
> the Session, the MessageProducer and the MessageConsumer objects should not
> be shared across threads in a Java application.
>
> However, the the examples that come with ActiveMQ CPP... the onMessage
> function uses the session, consumer objects. I think the onMessage would be
> called in seperate threads for each message in the queue. So given that
> session and consumer classes are not threadsafe...is it correct to do so?
>
> thanks
> Nishant
>
While the spec defines that certain types be thread safe we've shrived
to ensure that all operations on the CMS objects are thread safe. That
being said I would advise showing constraint on overusing CMS objects in
a method like onMessage as the time spent in that method delays delivery
of messages, so you wouldn't want to start producing messages from
onMessage for instance.
Regards
Tim.
--
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/