开发者

Using a background thread vs. using a message queue

开发者 https://www.devze.com 2023-03-07 02:10 出处:网络
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,

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:

  1. Use ActiveMQ and send the object as an objectMessage to the queue for processing.
  2. 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. :-)

0

精彩评论

暂无评论...
验证码 换一张
取 消