6

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 options 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?

casperOne
  • 73,706
  • 19
  • 184
  • 253
Dave Maple
  • 8,102
  • 4
  • 45
  • 64

3 Answers3

7

Two words:

Guaranteed Delivery.

If thats important to you, then a message queue is what you want.

casperOne
  • 73,706
  • 19
  • 184
  • 253
Tim Jarvis
  • 18,465
  • 9
  • 55
  • 92
  • that is true. i could use a persistent queue which would improve the reliability across restarts and other server events. – Dave Maple May 18 '11 at 00:36
2

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.

Chris Dail
  • 25,715
  • 9
  • 65
  • 74
  • That's a good point -- a message queue might make more sense if this was necessary across the cluster but in this case since each server processes only a portion of the responses the Commands could be threaded per server. On the other hand the persistent queue would improve reliability ... – Dave Maple May 18 '11 at 00:47
  • @Dave Correct, it would improve reliability. Is that a requirement here? Keep in mind, if you app crashes, does it matter if events are lost? It depends on the application type if that matters or not. – Chris Dail May 18 '11 at 00:49
  • 100% reliability is not a requirement in this case but it doesn't hurt anything to expect reliable alerting and I haven't yet started writing the code ... do you have any general sense from your experience of the resource cost of one vs. the other? – Dave Maple May 18 '11 at 00:52
  • @Dave JMS is more heavyweight. You need to be concerned with deployment, config etc of your JMS server in addition to your app. I tend toward lightweight approaches and later add complexity if required. You can always add a JMS queue later if you need. – Chris Dail May 18 '11 at 00:55
  • in this case ActiveMQ is already running inside the jvm and handling other asynchronous tasks if that matters: vm://localhost?broker. It it deployed to each server with the app so there is no dedicated JMS server for this app. – Dave Maple May 18 '11 at 01:00
1

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. :-)

NateTheGreat
  • 2,295
  • 13
  • 9
  • yeah, i'm leaning that way too. i should mention that activemq is already doing a bunch of stuff in this app and is running in the jvm with the webapp. – Dave Maple May 18 '11 at 00:35