The javax.jms.Queue and javax.jms.Topic objects have no explicit correlation to any resource on the broker. Holding them has no impact on broker operation. The JavaDoc [1] for the createQueue method states:
> Note that this method simply creates an object that encapsulates the name of a queue. It does not create the physical queue in the JMS provider. JMS does not provide a method to create the physical queue, since this would be specific to a given JMS provider. Creating a physical queue is provider-specific and is typically an administrative task performed by an administrator, though some providers may create them automatically when needed. The one exception to this is the creation of a temporary queue, which is done using the createTemporaryQueue method. The JavaDoc for createTopic has an equivalent statement. Hope that helps. Justin [1] https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createQueue-java.lang.String- On Fri, Dec 23, 2022 at 3:36 PM John Lilley <john.lil...@redpointglobal.com.invalid> wrote: > Justin, > > > > I am in the process of transforming our code to use a pool of sessions and > producers. But I have a question about resource use. We tend to have a > lot of queues, because each “job” gets its own queue, and there might be > 300 jobs that come and go every hour. When using a JMS client, does > holding a lot of Queue objects induce any resource consumption on the > broker (i.e. does it keep Addresses or Queues from being auto-deleted?) I > notice that Queue has no close(), so it is unclear how I would release > these resources even if I wanted to. > > > > Thanks > > John > > > > > > > [image: rg] <https://www.redpointglobal.com/> > > John Lilley > > Data Management Chief Architect, Redpoint Global Inc. > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > *From:* Justin Bertram <jbert...@apache.org> > *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. **** > > > > 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 < > john.lil...@redpointglobal.com.invalid> wrote: > > 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? I can arrange to > lock(session){} when messages are sent. > > And would reducing the number of sessions save any noticeable amount of > resource (time, or broker memory?). We tend to have about 20 producers per > process. > > > > Thanks > > John > > > > > > [image: rg] > <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,HUF5CPMqqSHkR0HMR73yG3n3O2OWw05JLoRMvNV8GeuRoVT4WcLkcg1DWq1M4uFenUmhrW-XKemVLg9pUBjWkBD-IsXkzUlFVX_5YEzBlgKeY-XrHQ,,&typo=1> > > *John Lilley * > > *Data Management Chief Architect, Redpoint Global Inc. * > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. > > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. >
