Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Lightweight messaging (async invocations) in Java

Tags:

java

messaging

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?

like image 459
Sergey Mikhanov Avatar asked Oct 17 '08 08:10

Sergey Mikhanov


4 Answers

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.

like image 139
James Strachan Avatar answered Nov 04 '22 10:11

James Strachan


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

like image 41
Chris Jester-Young Avatar answered Nov 04 '22 09:11

Chris Jester-Young


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.

like image 2
David Roussel Avatar answered Nov 04 '22 10:11

David Roussel


Sorry for resurrecting an old thread, but maybe it helps somebody else reading it... I think FFMQ 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.

like image 1
John Roberts Avatar answered Nov 04 '22 11:11

John Roberts