Thanks very much Matt. We are planning for any one of the two options : 1) Implement specific access policies for the MQ objects at the broker level 2) Pre-create the MQ objects and disable auto-creation. Most probably, option 2 might give a better control from middleware admin perspective, I guess.
Thanks & Regards, · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · Alban Soosai Nayagam Senior Middleware Engineer – MIDDLEWARE-TR Thomson Reuters C 1-437-241-6539 Escalation -----Original Message----- From: Matt Pavlovich <[email protected]> Sent: September 8, 2025 11:03 PM To: [email protected] Subject: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure External Email: Use caution with links and attachments. Hi Alban- Destinations are case sensitive. Setup the permissions and any clients with the incorrect format, invalid case, or syntax will get a permission denied error. Matt Pavlovich > On Sep 7, 2025, at 2:37 PM, Soosai Nayagam, Alban S. (TR Technology) > <[email protected]> wrote: > > Hi All, > > We used to work with IBM MQ so far in our environment and currently in the > process of migrating to ActiveMQ Classic(5.x). With IBM MQ, we used to create > the MQ objects well in advance before handing over to application teams. With > ActiveMQ, it was noticed that the broker has the ability to auto-create the > queues and topics whenever the applications send a request for access. Also, > it was noticed that there is a possibility for multiple objects being created > corresponding to a single destination object. For example, with auto-creation > allowed at one of our DEV broker, based on transactions from the > applications, one of the destination queue objects "Q01.REPLY" was > auto-created four times with multiple names "Q01.REPLY", "q01.reply", > "queue://Q01.REPLY" and "queue://queue://Q01.REPLY". The business > applications obviously cannot work properly with these four different queue > objects because they all need to publish and consume from the queue > "Q01.REPLY" only. > > In this regard, can any of you please let me know what is the best practice > to be used for controlling the creation of ActiveMQ objects properly so that > the above mentioned scenario is effectively addressed? > > Thanks & Regards, > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * Alban Soosai Nayagam Senior Middleware > Engineer - MIDDLEWARE-TR Thomson Reuters C 1-437-241-6539 > Escalation<https://urldefense.com/v3/__https://trten.sharepoint.com/si > tes/intr-ihn-service-portfolio/SitePages/IHN-Contact-*26-Escalation(1) > .aspx__;JQ!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5 > WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCmHqb0T8$ > > > This e-mail is for the sole use of the intended recipient and contains > information that may be privileged and/or confidential. If you are not > an intended recipient, please notify the sender by return e-mail and > delete this e-mail and any attachments. Certain required legal entity > disclosures can be accessed on our website: > https://www.thomsonreuters.com/en/resources/disclosures.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://urldefense.com/v3/__https://activemq.apache.org/contact__;!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCzKJ4Vv8$
