> 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> 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.
>
>
>
> [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
>
> -----Original Message-----
> From: Michael Brennock <mbrenn...@gmail.com>
> Sent: Friday, January 6, 2023 12:50 PM
> 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. ***
>
> 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>
> 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>
> > 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>
> 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>
> > > > 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.
>
