Of course, but who reads the spec before coding? 😉 I appreciate the Artemis is more compliant with and enforcing of the spec than AMQ 5 was. Because now I don’t have to read it!
john [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<tel:+1%207209385761> | john.lil...@redpointglobal.com<mailto:john.lil...@redpointglobal.com> From: Justin Bertram <jbert...@apache.org> Sent: Wednesday, January 11, 2023 9:53 AM To: users@activemq.apache.org Subject: Re: Looking for guidance on conversion from embedded activemq to artemis *** [Caution] This email is from an external source. Please use caution responding, opening attachments or clicking embedded links. *** > In particular, AMQ 5 let's you create several objects off the same Session > and use them concurrently... For what it's worth, the JMS specification states that Session objects are *not* thread-safe so any concurrent use is a spec violation. You may find implementations where concurrent use happens to work or may, in fact, be explicitly designed to work, but relying on non-spec behavior is not recommended as it handicaps portability (as you have found). Justin On Tue, Jan 10, 2023 at 11:18 AM John Lilley <john.lil...@redpointglobal.com.invalid<mailto:john.lil...@redpointglobal.com.invalid>> wrote: Michael, We have recently migrated from AMQ 5 to Artemis, and we used embedded brokers for testing, so I might be able to help. Jolokia (web service API) is not available in the embedded brokers, we migrated to using the queue-based management API instead for things like queue counts and lists. But I think that absence of the web server is true for both AMQ 5 and Artemis. We create the embedded broker using EmbeddedActiveMQ broker = new EmbeddedActiveMQ(); broker.setConfigResourcePath("mybroker.xml"); broker.start(); where mybroker.xml is the Artemis broker.xml file stored as a top-level java resource We found that Artemis is much more strict about prohibiting multi-thread access to JMS objects than AMQ 5, and we had to refactor some code because of that. In particular, AMQ 5 let's you create several objects off the same Session and use them concurrently; Artemis does not, you must make a new Session for each. Artemis clients use thread pooling; it is much more efficient and you can create many more MessageListener instances without incurring a lot of idle threads. We found that using session/producer pooling was more important with Artemis than it was with AMQ 5, because of increased broker memory footprint* for queues and sessions. That being said, pooling is awesome. Similarly, we found RPC reply-to queue pooling to also be important. * We did not measure this directly with controlled testing. Memory observations came from production systems running load tests and there could have been other factors such as session leakage. [rg]<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,m7wjxQ58SiRPmCyd051-AQ1J7zt4JaecjlE8KfbXONzSvftsKbUMo1R7tl_-sUAfLJ_Ii6x2oGTyOvvvdMF-qFLzOzF2j1k97DFWlYfu86qW&typo=1> John Lilley Data Management Chief Architect, Redpoint Global Inc. 888 Worcester Street, Suite 200 Wellesley, MA 02482 M: +1 7209385761<tel:+1%207209385761> | john.lil...@redpointglobal.com<mailto:john.lil...@redpointglobal.com> -----Original Message----- From: Michael Brennock <mbrenn...@gmail.com<mailto:mbrenn...@gmail.com>> Sent: Friday, January 6, 2023 12:50 PM To: users@activemq.apache.org<mailto:users@activemq.apache.org> Subject: Re: Looking for guidance on conversion from embedded activemq to artemis *** [Caution] This email is from an external source. Please use caution responding, opening attachments or clicking embedded links. *** Thank you for your feedback Justin. I will be more specific in my descriptions. * First, the activeMQ application creates an instance of BrokerService from BrokerFactory.createBroker(), with a activemq-config.xml for its argument * Next, the queues themselves are loaded one at a time by locating their beans. The beans are wired in the classic spring fashion from eps.broker.xml. The connected are created with ConnectionFactory and started with start() * (I'm perfectly happy to update this to the Artemis configuration file method instead) If I understand correctly, I need to replace the references to activemq-broker-initializer with EmbeddedActiveMQ, which comes from Artemis. Next, I need to use ConnectionFactory and Queue classes from JMS to add the message queues to the embedded server I created with EmbeddedActiveMQ. Is that at least heading in the right direction? Thanks again for your help, Michael On Fri, Jan 6, 2023 at 11:16 AM Justin Bertram <jbert...@apache.org<mailto:jbert...@apache.org>> wrote: > There's just not enough detail in what you've stated to provide any > concrete help with your migration. > > You said, "...it looks like BrokerService is used throughout the > application," but you've provided no details about how BrokerService > is used. Most applications using an embedded broker are pretty > straightforward when it comes to broker configuration. They typically > create a broker instance, configure it with a few endpoints (e.g. > queues, topics, etc.), configure a couple of other parameters, start > it, use it, and when the application is done it shuts the broker down. > Does your application follow this basic pattern? Does it configure the > broker programmatically or does it load configuration files? Does it > rely on automatic creation of endpoints? > > In order to replace BrokerService with EmbeddedActiveMQ we need > specific details about how BrokerService is being used. > > Hope that helps! > > > Justin > > On Fri, Jan 6, 2023 at 12:21 PM Michael Brennock > <mbrenn...@gmail.com<mailto:mbrenn...@gmail.com>> > wrote: > > > Thanks for the quick reply! > > > > For a more specific question, it looks like BrokerService is used > > throughout the application, as well as the active-mq-initializer > > bean > from > > activeMQ. > > To clarify, I inherited this project from other developers who are > > long gone. I started working on this because I briefly worked on a > > message > queue > > system before. > > > > On Thu, Jan 5, 2023, 8:41 PM Justin Bertram > > <jbert...@apache.org<mailto:jbert...@apache.org>> wrote: > > > > > EmbeddedActiveMQ is the class you want to use for embedding > > > ActiveMQ Artemis. The BrokerService is a class from ActiveMQ > > > "Classic". It is > used > > > in the ActiveMQ Artemis code-base only for testing purposes. You > > > won't > > use > > > it at all when migrating. > > > > > > For additional help you'll have to ask more specific questions. > > > > > > > > > Justin > > > > > > On Thu, Jan 5, 2023 at 4:45 PM Michael Brennock > > > <mbrenn...@gmail.com<mailto:mbrenn...@gmail.com>> > > > wrote: > > > > > > > Good afternoon, > > > > I've been tasked to migrate an existing application's message > > > > broker > > from > > > > ActiveMQ to Artemis. I was wondering if I could get some help > > > > troubleshooting my solution? > > > > > > > > We had some initial success replacing our embedded activeMQ > > > > broker > > with a > > > > standalone broker that runs outside the application and still > > > > uses > the > > > > original message queues defined in activeMQ. I tried to follow > > > > the information in this guide for creating either an > > > > EmbeddedActiveMQ or > a > > > > BrokerService. Something about the intended design path is > > > > unclear to > > me, > > > > even after reading the manual (1) and scouring the code from the > github > > > > page for answers (2) > > > > > > > > Can anyone offer advice on how to migrate from embedded ActiveMQ > > > > to embedded Artemis? I feel like I missed something important in > > > > the > > > migration > > > > documentation > > > > > > > > (1) > > > > > > > > > > > > > > https://activemq.apache.org/components/artemis/documentation/latest/em > bedding-activemq.html > > > > > > > > > > > > (2) > https://github.com/apache/activemq-artemis/search?q=brokerService > > > > > > > > > > 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.
