RE: session sharing question

2022-12-29 Thread John Lilley
stin Bertram Sent: Friday, December 23, 2022 4:08 PM To: users@activemq.apache.org Subject: Re: session sharing question *** [Caution] This email is from an external source. Please use caution responding, opening attachments or clicking embedded links. *** The javax.jms.Queue and javax.jms.T

Re: session sharing question

2022-12-23 Thread Justin Bertram
f Architect, Redpoint Global Inc. > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > *From:* Justin Bertram > *Sent:* Wednesday, December 21, 2022 12:49 PM > *To:* users@activemq.apache.

RE: session sharing question

2022-12-23 Thread John Lilley
12:49 PM To: users@activemq.apache.org Subject: Re: session sharing question *** [Caution] This email is from an external source. Please use caution responding, opening attachments or clicking embedded links. *** Generally speaking I would recommend delegating everything you can to a connecti

RE: session sharing question

2022-12-21 Thread John Lilley
:john.lil...@redpointglobal.com> From: Justin Bertram Sent: Wednesday, December 21, 2022 12:49 PM To: users@activemq.apache.org Subject: Re: session sharing question *** [Caution] This email is from an external source. Please use caution responding, opening attachments or clicking embedded links. **

Re: session sharing question

2022-12-21 Thread Justin Bertram
Generally speaking I would recommend delegating everything you can to a connection pool (e.g. this [1]) and spend your developer productivity elsewhere. Justin [1] https://github.com/messaginghub/pooled-jms On Wed, Dec 21, 2022 at 1:02 PM John Lilley wrote: > Greetings! > > > > I have noticed

Re: session sharing question

2022-12-21 Thread Justin Bertram
JMS Session objects have never been thread safe. You can use them however you want as long as you guarantee thread safety. That said, thread safety is notoriously difficult to implement & debug and Sessions are considered "lightweight" objects so there's not much cost to creating a Session for ever

Re: session sharing question

2022-12-21 Thread Jan Å mucr
My producers used to leak sessions and I could get easily as far as about 16k sessions per producer without much effect on the broker. What I do now is that I have a pool of worker threads, and each of the threads has its own session opened. Whenever there's a need, I ask the pool to do a Calla

session sharing question

2022-12-21 Thread John Lilley
Greetings! I have noticed that I cannot share a session between threads, at least not when using the JMS API. Because of that, we are creating a new session for every producer. But is that necessary? Can I share that session between all of my producers so long as there is no simultaneous use?