Develop Reference

When using Spring Boot and STOMP, is there a way to make queues not delete messages?

I have an application that uses Java on the backend end, Angular on the frontend, and I'm trying to use STOMP messaging between the two to exchange state data.
What I would like to do is have my services, on startup, publish their states and have that data stay in the queue for any client that later connects to the server.
(edit)
For clarification, I don't mean I want to messages to survive a server reboot. What I want is for certain message queues to retain all messages until the server reboots.
How do I tell Spring Boot's STOMP implementation to not delete the contents of a /queue?

You can configure ActiveMQ Artemis as an "external broker" and use a "non-destructive" queue. When a STOMP client receives and acknowledges a message from a non-destructive queue the broker will not remove it. You can define a special "initialization" queue which all clients connect to initially to receive the state data which you care about and then they can connect to whatever other queues they need to complete their normal work.
In this kind of use-case the queue is typically configured as non-destructive and as a "last value" queue. This way each client can use its own "last value" and can keep their state data up-to-date without the complication of stale state data on the queue.
I realize your question was asking about how to do this with Spring's built-in broker, but all my research indicates that Spring's simple in-memory broker neither supports last-value queue semantics nor non-destructive queue semantics nor even persistent messages. From what I understand Spring's broker is only meant for the most basic use-cases which is why then enable integration with 3rd party brokers which can support more advanced use-cases (e.g. like yours).

How to manage messages in apache ActiveMQ

I have Apache ActiveMQ embedded into my java 8 server side project. Its working fine, and I am able to send and consume messages from pre-configured queues. I now need to be able programatically remove messages from the queue upon request. After reading some docs I found that Apache ActiveMQ has a sub-project called Artemis that seems to provide the required functionality. But I am a bit confused on how to do it. Is Artemis sort of plugin on top of ActiveMQ and I just need to add required dependencies and use the tools or is it a separate product and it doesn't work with Active MQ but as an independent product. If so how do I manage individual messages (in particular delete requested message) in Active MQ?

First off, 'ActiveMQ Artemis' is a sub-project within the ActiveMQ project that represents an entirely new broker with a radically different underlying architecture than the main ActiveMQ broker. You would run one or the other.
To manage messages in the ActiveMQ broker you would use the JMX Mamagement API and the Queue#remove methods it exposes to remove specific messages. This can be done using the Message ID or more broadly using a message selector to capture more than one message if need be. The JMX API is also exposed via Jolokia so that you can manage the broker via simple REST calls instead of the JMX way if you prefer.
In any case this sort of message level management on the broker is a bit of an anti-pattern in the messaging world. If you find yourself needing to treat the broker as a database then you should ask yourself why you aren't using a database since a broker is not a database. Often you will run into many more issues trying to manage your messages this way as opposed to just putting them into a database.

Why is Mule required if we have Active MQ?

I am working as a software engineer on a project which uses ActiveMQ and Mule for Java Messaging Service. But I have one question: since ActiveMQ is transferring all message to one queue to another queue, why Mule is required?

The above image is from the official Mule 3 User Manual
Following is a very simplistic overview to give you a general idea. Without knowing the specifics about your application, its difficult to tell how everything works together.
Mule is not a message broker, it is a service bus; it provides integration and communication services. In a basic form, it can act like a message broker, but that's just a side effect of any integration layer.
The real power of mule is the various integration points across different applications, system, and services; providing for security, reporting, etc.
ActiveMQ is just a message broker - whole job is to effectively provide a messaging bus. Mule takes different requests, transform/translates them, logs them, and may then posts them on to ActiveMQ as part of its defined flow.
It could also be that ActiveMQ is acting as the queue for messages that later need to be processed through Mule (as in the image above).
Mule can use ActiveMQ as a message source and destination. Using MQ in such a way provides a guarantee that messages will be processed and none are lost.

JMS client applications and the Business Activity Monitor

I was wondering if there was a way to connect to the Business Activity Monitor located on a WebLogic server via the client applications. I am wanting to replace the log statements in my JMS Producer/Consumer clients with BAM statements so BAM is updated with message progress/errors? I am hoping there is an API for this, but have not been successful in locating it?

Oracle BAM is able to consume XML messages from a queue or a topic as input for a data item. Here is BAM configuration documentation to do so.
As your client application is already JMS based, it should be easy to make them send additional JMS messages to a dedicated queue for progress monitoring in BAM.
Beware of the transaction demarcation: you have to take care if your BAM message is supposed to be included in the same transaction as your regular business or in a specific one, to avoid a rollback in case of business failure.

Using JMS or ThreadPool to send email messages

I will like to know:
I have a scenario. If a user adds a product to the system (I'm developing), there's a listener that sends a notification to the user's client base notifying of a new product added by the user.
I've read this thread and (seeing I've never used JMS nor ThreadPool before) I was wondering whether I should use JMS or ThreadPooling.
I am using Tomcat 5.5 and higher and JBoss 5 and higher (depending on company last resort) to deploy my web application.
If I use JMS, do I use Apache ActiveMQ or JBoss Messaging? Are they both compatible to run on both platforms (Tomcat and JBoss)?
Thanks in advance.

For communicating between applications, JMS is a very good solution, especially for events and notifications. JMS allows for such notifications to be sent and received using what is known as asynchronous messaging whereby the sender and receiver have no knowledge of one another and no requirement to be available at the same time.
ActiveMQ is a very widely used message broker that provides client APIs for Java, C/C++, C#, Perl, PHP, Python, Ruby and more. This allows the use of JMS with applications written in Java and other languages.
I have implemented JMS messaging many, many times for a large variety of business situations to handle events and notifications. The vast majority of these times, I have recommended and/or used Spring JMS no matter what message broker is being used. Spring JMS is incredibly easy to use, extremely robust and highly scalable. Spring JMS removes the complexity of creating your own message producers and message consumers, which can save you a tremendous amount of time.
To see how easy it is to send messages using Spring JMS, check out a blog post I wrote recently titled Using the Spring JmsTemplate to Send JMS Messages. I'm also working on a blog post about receiving messages using Spring JMS.
If you have any further questions, let me know.
Bruce

I had a similar requirement once, and we used JMS. Then main problem was how to deal with errors because SMTP is indeed not transactional:
is it ok if some email are lost?
is it ok if some email are sent twice?
We decided it was better to send the message twice, and here is more or less the design we had:
We relied on container managed transaction and if for some reason the email can not be sent, we decided to rollback the JMS transaction; the message would be redelivered later by JMS and an new attempt to send the message was done.
If the JMS message delivery transaction failed after the email was sent (e.g. because of a problem with JMS), the transaction would be rolled back automatically and the message was redelivered later. In this case, the email was sent twice because STMP is not transactional.
Even if the email can be sent (from point of view of code), the SMTP server can still have problem later. In this case, the JMS have been delivered and consumed, so we had no way to know which email had been processed and how to re-send them manually.
But we were already using JMS. I would not introduce JMS just for that given that the main argument is that JMS is transactional, but SMTP isn't anyway.
I would go for something lighter -- possibly with a ThreadPool -- and store the state in a database to know which email need to be sent or has been sent. If there are some problem, you can look at the database and take the ad-hoc decisions.

I know that this reply is very late to this dicsussion, but I hope it will still be valuable for folks seeking info on integrating ActiveMQ and Tomcat.
I've had many people ask me for help with issues they have had integrating ActiveMQ and Tomcat so I decided to write some articles about it. Not only is this topic covered in ActiveMQ in Action (see chapter 8), but I also published a series of articles on it titled ActiveMQ and Tomcat: Perfect Partners. Hopefully people will find this helpful.

I would go for a persistent JMS (I have used only WLS JMS and Websphere MQ so can't compare AQ vs JBoss, whichever offers a better guarantee for delivery). Also, I would seriously consider making the email engine a completely separate application, depending on how much you expect the traffic to grow.