Using a background thread vs. using a message queue
I'm currently working on a series of alerts that will examine the status of a response from a foreign web service and send alerts based on the status of the the response object (for example timeouts, invalid data etc.). I want the main thread to continue working while the response is evaluated and alerts are sent.
I have two immediate option开发者_运维知识库s available to me:
- Use ActiveMQ and send the object as an objectMessage to the queue for processing.
- Use a command pattern and thread an asynchronous command that handles the alert.
They both seem like pretty good options to me but I'm leaning toward the threaded command since I don't need most of the features of a message queue.
Question: How would you decide which to use and why?
Two words:
Guaranteed Delivery.
If thats important to you, then a message queue is what you want.
It sounds like you are putting something together to handle events within your application. For that you have a lot of options in the java.util.concurrent package. A message queue is good for guaranteeing delivery (can give persistence) and allowing messages to multiple servers.
The util.concurrent's ExecutorService allows you to submit a task to be executed on a thread pool. The future it returns allows you to continue processing and check the results at a later time.
Future<?> submit(Runnable task)
If that is not exactly what you need, there are probably other options within java.util.concurrent.
I would decide based on what you are already thinking... that a full blown message queue, while very powerful, is way bigger than you need. Not to mention that it's another process/server/etc. So, I'd vote for the second option. :-)
精彩评论