Lightweight messaging (async invocations) in Java
Asked Answered
T

5

10

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?

Thirty answered 17/10, 2008 at 8:53 Comment(0)
P
5

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.

Promethean answered 17/10, 2008 at 9:49 Comment(0)
B
5

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

Balmoral answered 17/10, 2008 at 8:57 Comment(0)
P
5

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.

Promethean answered 17/10, 2008 at 9:49 Comment(0)
L
2

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.

Lollygag answered 16/11, 2009 at 13:38 Comment(0)
J
1

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.

Joachima answered 11/6, 2010 at 15:20 Comment(0)
W
0

For help to somebody else read this thread:
One of the lightest messaging framework is Mbasseder. MBassador is a very light-weight message (event) bus implementation following the publish subscribe pattern. It is designed for ease of use and aims to be feature rich and extensible while preserving resource efficiency and performance.
The core of MBassador's high performance is a specialized data structure that minimizes lock contention such that performance degradation of concurrent access is minimal.
Features: Declarative listener definition via annotations, sync and/or async event delivery, weak-references, message filtering

Willette answered 22/11, 2014 at 7:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.