You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Soosai Nayagam, Alban S. (TR Technology)" <Al...@thomsonreuters.com.INVALID> on 2025/09/07 19:37:15 UTC
Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
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://trten.sharepoint.com/sites/intr-ihn-service-portfolio/SitePages/IHN-Contact-%26-Escalation(1).aspx>
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
Re: [EXT] Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Posted by Matt Pavlovich <ma...@apache.org>.
Keep in mind that ActiveMQ supports namespaces/multi-tenancy, so you can split the difference =)
Matt Pavlovich
> On Sep 9, 2025, at 1:26 PM, Soosai Nayagam, Alban S. (TR Technology) <Al...@thomsonreuters.com.INVALID> wrote:
>
> 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 <ma...@apache.org>
> Sent: September 8, 2025 11:03 PM
> To: users@activemq.apache.org
> 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) <Al...@thomsonreuters.com.INVALID> 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: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org For further information, visit: https://urldefense.com/v3/__https://activemq.apache.org/contact__;!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCzKJ4Vv8$
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Posted by "Soosai Nayagam, Alban S. (TR Technology)" <Al...@thomsonreuters.com.INVALID>.
Thanks Vilius for the suggestion.
-----Original Message-----
From: Vilius Šumskas <vi...@rivile.lt.INVALID>
Sent: September 9, 2025 4:12 PM
To: users@activemq.apache.org
Subject: RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Hi,
since the title of this thread is about "best practices" :), I would recommend to go with option 1).
The best practice is that messaging objects (addresses, queues, ttl settings, etc) should be managed by the application. Think of it the same way as database schema. This "schema" defines routing between services, but how it should happen is internal to those services, and not really a job of the operator. Operator's job is to ensure that applications has access to only their area of a broker, and that they don't kill the broker because of resource exhaustion, or for whatever other reason.
Also, it is usually much easier to do all the CI/CD pipelines this way, because application developers have better tools integrated to precreate/migrate/delete these objects during deployment of new versions.
--
Best Regards,
Vilius
-----Original Message-----
From: Soosai Nayagam, Alban S. (TR Technology) <Al...@thomsonreuters.com.INVALID>
Sent: Tuesday, September 9, 2025 9:27 PM
To: users@activemq.apache.org
Subject: RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
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 <ma...@apache.org>
Sent: September 8, 2025 11:03 PM
To: users@activemq.apache.org
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) <Al...@thomsonreuters.com.INVALID> 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: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org For further information, visit: https://urldefense.com/v3/__https://activemq.apache.org/contact__;!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCzKJ4Vv8$
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ \ \ ][ X ܚX PX ] [\K \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] [\K \X K ܙ B ܈ \ \ [ ܛX][ۋ \ ]
X ] [\K \X K ܙ X B B
RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Posted by Vilius Šumskas <vi...@rivile.lt.INVALID>.
Hi,
since the title of this thread is about "best practices" :), I would recommend to go with option 1).
The best practice is that messaging objects (addresses, queues, ttl settings, etc) should be managed by the application. Think of it the same way as database schema. This "schema" defines routing between services, but how it should happen is internal to those services, and not really a job of the operator. Operator's job is to ensure that applications has access to only their area of a broker, and that they don't kill the broker because of resource exhaustion, or for whatever other reason.
Also, it is usually much easier to do all the CI/CD pipelines this way, because application developers have better tools integrated to precreate/migrate/delete these objects during deployment of new versions.
--
Best Regards,
Vilius
-----Original Message-----
From: Soosai Nayagam, Alban S. (TR Technology) <Al...@thomsonreuters.com.INVALID>
Sent: Tuesday, September 9, 2025 9:27 PM
To: users@activemq.apache.org
Subject: RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
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 <ma...@apache.org>
Sent: September 8, 2025 11:03 PM
To: users@activemq.apache.org
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) <Al...@thomsonreuters.com.INVALID> 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: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org For further information, visit: https://urldefense.com/v3/__https://activemq.apache.org/contact__;!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCzKJ4Vv8$
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
\ \ ][ X ܚX PX ] [\K \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
\ \ Z[ X ] [\K \X K ܙ B ܈ \ \ [ ܛX][ۋ \ ]
X ] [\K \X K ܙ X B B
RE: [EXT] Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Posted by "Soosai Nayagam, Alban S. (TR Technology)" <Al...@thomsonreuters.com.INVALID>.
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 <ma...@apache.org>
Sent: September 8, 2025 11:03 PM
To: users@activemq.apache.org
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) <Al...@thomsonreuters.com.INVALID> 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: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org For further information, visit: https://urldefense.com/v3/__https://activemq.apache.org/contact__;!!GFN0sa3rsbfR8OLyAw!fNSLcujNpGtbaA92Bo3Gmi5vphTsOuQyHSpDtC5WO3DHKevO8oRNIYtAm9wW_ps3JElA5UsmxOyrqTc7P3Dv8fBCzKJ4Vv8$
Re: Question on Best Practices to be Used for Object Creation in an ActiveMQ Classic Infrastructure
Posted by Matt Pavlovich <ma...@apache.org>.
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) <Al...@thomsonreuters.com.INVALID> 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://trten.sharepoint.com/sites/intr-ihn-service-portfolio/SitePages/IHN-Contact-%26-Escalation(1).aspx>
>
> 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: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact