You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by David Crisp <da...@yahoo.com> on 2008/08/07 20:41:48 UTC
(hopefully) simple JMS question
Hi,
I have a quick question regarding the JMS spec and I was hoping to
solicit
feedback from our merry band of domain experts.
Given that Sessions are not thread-safe, if I'm creating a little
client-side
API that gets hit by a myriad of threads and do not want to synchronize
the API points, I need to create a new Session on the stack for each
thread context. Destinations ARE thread safe, but are created via a
specific Session instance. Given this, can I assume that destination
instances
remain valid even after the Session that created them is destroyed? I've
looked at
the JMS spec and it seems fairly silent on this point.
Thanks in advance,
D.
P.s. I'm assuming this must be true given that Destination creation can't
be cheap since it requires communication with the broker.
--
View this message in context: http://www.nabble.com/%28hopefully%29-simple-JMS-question-tp18877105p18877105.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: (hopefully) simple JMS question
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Aug 7, 2008 at 1:22 PM, Joe Fernandez
<jo...@ttmsolutions.com> wrote:
>
> The 'temporary' destinations behave a little differently. A temporary
> destination's lifetime is that of the connection that created it. I'd
> recommend reusing session objects if you can. They, along with the Producer
> and Consumer objects, are lightweight objects, but creating and destroying
> them generates network traffic to and from the broker.
Very good points with the temp destinations, Joe ;-). Something I
neglected to explain.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Blog: http://bruceblog.org/
Re: (hopefully) simple JMS question
Posted by David Crisp <da...@yahoo.com>.
Interesting. So if you had an API that acquired data via Java remoting and
was potentially accessed by a couple thousand threads concurrently, it
sounds like a pool of broker connections, each with an associated
ThreadLocal for session storage, might do the trick. It would result in
some wasted storage since each connector would eventually end up with a
session for each client thread, but that out of process communication cost
would only be incurred the first time a specific thread grabbed a connection
from the pool. The JMS spec includes a reference to a SessionPool
interface, but it looks like it's intended for use in high-volume consumers,
not RPC-style clients. Is that correct?
Thanks,
D.
Joe Fernandez wrote:
>
> The 'temporary' destinations behave a little differently. A temporary
> destination's lifetime is that of the connection that created it. I'd
> recommend reusing session objects if you can. They, along with the
> Producer and Consumer objects, are lightweight objects, but creating and
> destroying them generates network traffic to and from the broker.
>
> Joe
> www.ttmsolutions.com
>
>
>
> bsnyder wrote:
>>
>> On Thu, Aug 7, 2008 at 12:41 PM, David Crisp <da...@yahoo.com>
>> wrote:
>>>
>>> Hi,
>>> I have a quick question regarding the JMS spec and I was hoping to
>>> solicit
>>> feedback from our merry band of domain experts.
>>>
>>> Given that Sessions are not thread-safe, if I'm creating a little
>>> client-side
>>> API that gets hit by a myriad of threads and do not want to synchronize
>>> the API points, I need to create a new Session on the stack for each
>>> thread context. Destinations ARE thread safe, but are created via a
>>> specific Session instance. Given this, can I assume that destination
>>> instances
>>> remain valid even after the Session that created them is destroyed?
>>> I've
>>> looked at
>>> the JMS spec and it seems fairly silent on this point.
>>>
>>> Thanks in advance,
>>> D.
>>>
>>> P.s. I'm assuming this must be true given that Destination creation
>>> can't
>>> be cheap since it requires communication with the broker.
>>
>> Yes, once a destination has been created, it will exist on the broker
>> even if the session that created it is destroyed. This is because the
>> session is simply used to interact with the broker and send it
>> commands.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache ActiveMQ - http://activemq.org/
>> Apache Camel - http://activemq.org/camel/
>> Apache ServiceMix - http://servicemix.org/
>>
>> Blog: http://bruceblog.org/
>>
>>
>
>
--
View this message in context: http://www.nabble.com/%28hopefully%29-simple-JMS-question-tp18877105p18878573.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: (hopefully) simple JMS question
Posted by Joe Fernandez <jo...@ttmsolutions.com>.
The 'temporary' destinations behave a little differently. A temporary
destination's lifetime is that of the connection that created it. I'd
recommend reusing session objects if you can. They, along with the Producer
and Consumer objects, are lightweight objects, but creating and destroying
them generates network traffic to and from the broker.
Joe
www.ttmsolutions.com
bsnyder wrote:
>
> On Thu, Aug 7, 2008 at 12:41 PM, David Crisp <da...@yahoo.com>
> wrote:
>>
>> Hi,
>> I have a quick question regarding the JMS spec and I was hoping to
>> solicit
>> feedback from our merry band of domain experts.
>>
>> Given that Sessions are not thread-safe, if I'm creating a little
>> client-side
>> API that gets hit by a myriad of threads and do not want to synchronize
>> the API points, I need to create a new Session on the stack for each
>> thread context. Destinations ARE thread safe, but are created via a
>> specific Session instance. Given this, can I assume that destination
>> instances
>> remain valid even after the Session that created them is destroyed?
>> I've
>> looked at
>> the JMS spec and it seems fairly silent on this point.
>>
>> Thanks in advance,
>> D.
>>
>> P.s. I'm assuming this must be true given that Destination creation
>> can't
>> be cheap since it requires communication with the broker.
>
> Yes, once a destination has been created, it will exist on the broker
> even if the session that created it is destroyed. This is because the
> session is simply used to interact with the broker and send it
> commands.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
>
> Blog: http://bruceblog.org/
>
>
--
View this message in context: http://www.nabble.com/%28hopefully%29-simple-JMS-question-tp18877105p18877836.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: (hopefully) simple JMS question
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Aug 7, 2008 at 12:41 PM, David Crisp <da...@yahoo.com> wrote:
>
> Hi,
> I have a quick question regarding the JMS spec and I was hoping to
> solicit
> feedback from our merry band of domain experts.
>
> Given that Sessions are not thread-safe, if I'm creating a little
> client-side
> API that gets hit by a myriad of threads and do not want to synchronize
> the API points, I need to create a new Session on the stack for each
> thread context. Destinations ARE thread safe, but are created via a
> specific Session instance. Given this, can I assume that destination
> instances
> remain valid even after the Session that created them is destroyed? I've
> looked at
> the JMS spec and it seems fairly silent on this point.
>
> Thanks in advance,
> D.
>
> P.s. I'm assuming this must be true given that Destination creation can't
> be cheap since it requires communication with the broker.
Yes, once a destination has been created, it will exist on the broker
even if the session that created it is destroyed. This is because the
session is simply used to interact with the broker and send it
commands.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Blog: http://bruceblog.org/