IMO, if you need features that ActiveMQ provides (publish/subscribe semantics (JMS Topics), message expiration, Virtual Topics) then an Embedded ActiveMQ broker makes sense. If SEDA does what you need, I think I’d stick with that.
> On Mar 29, 2017, at 6:23 AM, Mark Nuttall <[email protected]> wrote: > > Note that i will be using **embedded** ActiveMQ. (I tried to highlight that > in my question) Thus it will _not_ have persistence, reliability or be > distributed. > > So, in light that, does embedded ActiveMQ add any value over SEDA? Or does > it just add overhead (i.e. more memory, etc)? > > On Wed, Mar 29, 2017 at 8:12 AM, Muhzin <[email protected]> wrote: > >> The documentation of SEDA has the necessary clarification. >> >> >> The *seda:* component provides asynchronous SEDA >>> <http://www.eecs.harvard.edu/~mdw/proj/seda/> behavior, so that messages >>> are exchanged on a BlockingQueue >>> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/ >> concurrent/BlockingQueue.html> and >>> consumers are invoked in a separate thread from the producer. >>> This component does not implement any kind of persistence or recovery, if >>> the VM terminates while messages are yet to be processed. *If you need >>> persistence, reliability or distributed SEDA, try using either JMS >>> <http://camel.apache.org/jms.html> or ActiveMQ >>> <http://camel.apache.org/activemq.html>.* >> >> >> On Wed, Mar 29, 2017 at 5:33 PM, Mark Nuttall <[email protected]> wrote: >> >>> Which would be the better choice? SEDA or _embedded_ ActiveMQ? >>> >>> I've googled and read the docs. I am just doing some low volume, short >>> live processing and need async worker queues. My only other choice is SQS >>> and it seems like overkill and a lot of extra effort. >>> >> >> >> >> -- >> BR >> Muhsin >>
