Re: SEDA vs embedded ActiveMQ

:///user/SendEmail.jtp?type=node=5796700=3>> > > 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

Re: SEDA vs embedded ActiveMQ

Thanks for the reply. Yeah, it will just be simple pub/sub, no topics or message expiration. So, I think I will switch to SEDA. On Wed, Mar 29, 2017 at 9:53 AM, Quinn Stevenson < qu...@pronoia-solutions.com> wrote: > IMO, if you need features that ActiveMQ provides (publish/subscribe >

Re: SEDA vs embedded ActiveMQ

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

Re: SEDA vs embedded ActiveMQ

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,

Re: SEDA vs embedded ActiveMQ

The documentation of SEDA has the necessary clarification. The *seda:* component provides asynchronous SEDA > behavior, so that messages > are exchanged on a BlockingQueue >

SEDA vs embedded ActiveMQ

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.