tags:

views:

741

answers:

4

I am looking for lightweight messaging framework in Java. My task is to process events in a SEDA’s manner: I know that some stages of the processing could be completed quickly, and others not, and would like to decouple these stages of processing.

Let’s say I have components A and B and processing engine (be this container or whatever else) invokes component A, which in turn invokes component B. I do not care if execution time of component B will be 2s, but I do care if execution time of component A is below 50ms, for example. Therefore, it seems most reasonable for component A to submit a message to B, which B will process at the desired time.

I am aware of different JMS implementations and Apache ActiveMQ: they are too heavyweight for this. I searched for some lightweight messaging (with really basic features like messages serialization and simplest routing) to no avail.

Do you have anything to recommend in this issue?

+4  A: 

Really lightweight? Executors. :-) So you set up an executor (B, in your description), and A simply submits tasks to the executor.

Chris Jester-Young
+3  A: 

Do you need any kind of persistence (e.g. if your JVM dies in between processing thousands of messages) and do you need messages to traverse to any other JVMs?

If its all in a single JVM and you don't need to worry about transactions, recovery or message loss if a JVM dies - then as Chris says above, Executors are fine.

ActiveMQ is pretty lightweight; you can use it in a single JVM only with no persistence if you want to; you can then enable transactions / persistence / recovery / remoting (working with multiple JVMs) as and when you need it. But if you need none of these things then its overkill - just use Executors.

Incidentally another option if you are not sure which steps might need persistence/reliability or load balancing to multiple JVMs would be to hide the use of middleware completely so you can switch between in memory SEDA queues with executors to JMS/ActiveMQ as and when you need to.

e.g. it might be that some steps need to be reliable & recoverable (so needing some kind of persistence) and other times you don't.

James Strachan
+1  A: 

I think Apache Camel covers all your needs. It's works within the JVM and supports SEDA style (http://camel.apache.org/seda.html) and simpe routing. Can be used on it's own, or with spring, with a JMS provider or other adaptors.

David Roussel
+1  A: 

Sorry for resurrecting an old thread, but maybe it helps somebody else reading it... I think FFMQ (http://ffmq.sourceforge.net/) is a good candidate for a lightweight messaging framework.

UPDATE: however I'm not sure if it supports redelivery delays (the dead-letter-queue problem). I would find this usable even for lightweight providers. But I guess it could be possible with a combination of MessageSelector query and message properties.

John Roberts