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).
I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!
JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.
I am trying to understand the basics of Message Queues. I see that there are many implementations available as libraries for MQs (ActiveMQ, RabbitMQ, ZeroMQ etc). Also J2EE enabled servers provide such support I think.
What I fail to understand about the topic, is how are these kind of constructs used by real software. I mean what kind of messages are usually being exchanged? Strings? Binary data?
If I understand correctly one can configure the transport protocol, but what is usually the application data format?
Is it a new way of communication, like e.g. SOAP WS or REST WS or RPC etc where each has a different application msg format?
Message queues usually using for application integration. In enterprise it is usually used to implement ESB, but nowadays there are smaller application systems that utilize similar patterns.
Concerning data being transmitted - usually it is XML messages, but actually depends on applications and MQ software - some of them are able to handle binary messages, some are not.
For example imagine you have two applications which require data interchange. If you integrate them using some kind of messaging software such as ActiveMQ, for example, then it will give you some benefits like routing, fault-tolerance, balancing, etc, out-of-the-box.
You may integrate your applications using MQ directly, but ESBs usually
give you ability to use web services: app just calls ws of ESB and knows nothing about underlying architecture.
Also MQs and ESBs gives you a level of abstraction: you may switch your apps in a system absolutely transparent, as long as data exchange interface is preserved.
MQs are mainly used for interprocess communication, or for inter-thread communication within the same process. They provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
wikipedia can be good intro to topic. http://en.wikipedia.org/wiki/Message_queue#Standards_and_protocols
Also, to understand diff between webservice and mq, read this thread: Message Queue vs. Web Services?
I would like to implement asynchronous email sending in my web application when users register for a new account. This is so that if there is a problem or delay in sending the email message (e.g. the mail server is down or the network connection to the mail server is slow) the user won't be kept waiting for the sending to complete.
My web app is built using Spring and Hibernate's implementation of JPA.
What would be the best and most reliable way for me to implement asynchronous email processing in this web application?
I am thinking about persisting the email information in a database table which is then regularly polled by a Quartz (http://www.opensymphony.com/quartz/) scheduled job for updates and when it finds new unsent emails, it attempts to send them.
Is this a reasonable way of implementing what I want?
Thanks.
Edit:
The most voted on response is to leave the sending of mail as a synchronous call but what's triggered my thinking that an asynchronous approach might be best is that I'm currently using GMail as my outbound mail server (this is for testing while developing) and I'm experiencing a 25 second delay in response from when my app tries to send the email to when the call to the mail send function returns. What do you think?
I would suggest that you don't bother. Most Unix-style MTAs invented and perfected deferred sending decades ago, and you shouldn't be reinventing the wheel. You'll do it poorly (in comparison to sendmail or postfix), and you'll miss something. My best advice is to use the Java Mail APIS javax.mail and let the MTA deal with the asynchronous part.
You can implement queueing by hand, using MySQL or some other persistent mechanism, but you could also use JMS for queueing. It's pretty much a perfect match for just this kind of situations.
In that case I would be tempted by splitting the mail component off from the main app, and let the two communicate using JMS. The main app puts a message in the JMS and the mailer app would subscribe to the queue and try to process the messages.
JMS can be made persistent (to e.g. MySQL) pretty easily by configuration.
The advantage of spliting the webapp is that you abstract away the notification mechanism and could in the future implement e.g. Google Wave or IRC or whatever without having to touch your main app.
Someone else suggested to use a postfix or sendmail and let them handle the queueing. That is also a great solution, especially if you put the postfix or sendmail on localhost and let it route the messages further. Do try to configure that mailer program such that only mail from localhost is allowed to be routed, to prevent creating an open mailer :)
EDIT clarified the use of JMS + comment on local mailer daemon
It is fairly reasonable, this is the kind of thing Quartz was build for.
However, note that you don't need to schedule through the database at all (unless the server downtime is a real issue). You can simply schedule a Quartz job without database access (the simplest Quartz examples show you how).
Otherwise, if you do choose the database access you have the possibility of sending the emails from another application entirely (a nice thing if you need it).
Java EE 6 makes this so easy with the #Asynchronous annotation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I was just reading abit about JMS and Apache ActiveMQ.
And was wondering what real world use have people here used JMS or similar message queue technologies for ?
JMS (ActiveMQ is a JMS broker implementation) can be used as a mechanism to allow asynchronous request processing. You may wish to do this because the request take a long time to complete or because several parties may be interested in the actual request. Another reason for using it is to allow multiple clients (potentially written in different languages) to access information via JMS. ActiveMQ is a good example here because you can use the STOMP protocol to allow access from a C#/Java/Ruby client.
A real world example is that of a web application that is used to place an order for a particular customer. As part of placing that order (and storing it in a database) you may wish to carry a number of additional tasks:
Store the order in some sort of third party back-end system (such as SAP)
Send an email to the customer to inform them their order has been placed
To do this your application code would publish a message onto a JMS queue which includes an order id. One part of your application listening to the queue may respond to the event by taking the orderId, looking the order up in the database and then place that order with another third party system. Another part of your application may be responsible for taking the orderId and sending a confirmation email to the customer.
Use them all the time to process long-running operations asynchronously. A web user won't want to wait for more than 5 seconds for a request to process. If you have one that runs longer than that, one design is to submit the request to a queue and immediately send back a URL that the user can check to see when the job is finished.
Publish/subscribe is another good technique for decoupling senders from many receivers. It's a flexible architecture, because subscribers can come and go as needed.
I've had so many amazing uses for JMS:
Web chat communication for customer service.
Debug logging on the backend. All app servers broadcasted debug messages at various levels. A JMS client could then be launched to watch for debug messages. Sure I could've used something like syslog, but this gave me all sorts of ways to filter the output based on contextual information (e.q. by app server name, api call, log level, userid, message type, etc...). I also colorized the output.
Debug logging to file. Same as above, only specific pieces were pulled out using filters, and logged to file for general logging.
Alerting. Again, a similar setup to the above logging, watching for specific errors, and alerting people via various means (email, text message, IM, Growl pop-up...)
Dynamically configuring and controlling software clusters. Each app server would broadcast a "configure me" message, then a configuration daemon that would respond with a message containing all kinds of config info. Later, if all the app servers needed their configurations changed at once, it could be done from the config daemon.
And the usual - queued transactions for delayed activity such as billing, order processing, provisioning, email generation...
It's great anywhere you want to guarantee delivery of messages asynchronously.
Distributed (a)synchronous computing.
A real world example could be an application-wide notification framework, which sends mails to the stakeholders at various points during the course of application usage. So the application would act as a Producer by create a Message object, putting it on a particular Queue, and moving forward.
There would be a set of Consumers who would subscribe to the Queue in question, and would take care handling the Message sent across. Note that during the course of this transaction, the Producers are decoupled from the logic of how a given Message would be handled.
Messaging frameworks (ActiveMQ and the likes) act as a backbone to facilitate such Message transactions by providing MessageBrokers.
I've used it to send intraday trades between different fund management systems. If you want to learn more about what a great technology messaging is, I can thoroughly recommend the book "Enterprise Integration Patterns". There are some JMS examples for things like request/reply and publish/subscribe.
Messaging is an excellent tool for integration.
We use it to initiate asynchronous processing that we don't want to interrupt or conflict with an existing transaction.
For example, say you've got an expensive and very important piece of logic like "buy stuff", an important part of buy stuff would be 'notify stuff store'. We make the notify call asynchronous so that whatever logic/processing that is involved in the notify call doesn't block or contend with resources with the buy business logic. End result, buy completes, user is happy, we get our money and because the queue is guaranteed delivery the store gets notified as soon as it opens or as soon as there's a new item in the queue.
I have used it for my academic project which was online retail website similar to Amazon.
JMS was used to handle following features :
Update the position of the orders placed by the customers, as the shipment travels from one location to another. This was done by continuously sending messages to JMS Queue.
Alerting about any unusual events like shipment getting delayed and then sending email to customer.
If the delivery is reached its destination, sending a delivery event.
We had multiple also implemented remote clients connected to main Server. If connection is available, they use to access the main database or if not use their own database. In order to handle data consistency, we had implemented 2PC mechanism.
For this, we used JMS for exchange the messages between these systems i.e one acting as coordinator who will initiate the process by sending message on the queue and others will respond accordingly by sending back again a message on the queue.
As others have already mentioned, this was similar to pub/sub model.
I have seen JMS used in different commercial and academic projects. JMS can easily come into your picture, whenever you want to have a totally decoupled distributed systems. Generally speaking, when you need to send your request from one node, and someone in your network takes care of it without/with giving the sender any information about the receiver.
In my case, I have used JMS in developing a message-oriented middleware (MOM) in my thesis, where specific types of object-oriented objects are generated in one side as your request, and compiled and executed on the other side as your response.
Apache Camel used in conjunction with ActiveMQ is great way to do Enterprise Integration Patterns
We have used messaging to generate online Quotes
We are using JMS for communication with systems in a huge number of remote sites over unreliable networks. The loose coupling in combination with reliable messaging produces a stable system landscape: Each message will be sent as soon it is technically possible, bigger problems in network will not have influence on the whole system landscape...