You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Mark Nuttall <mk...@gmail.com> on 2017/03/29 12:03:50 UTC
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.
Re: SEDA vs embedded ActiveMQ
Posted by souciance <so...@gmail.com>.
The nice thing about SEDA is that it is built in Camel so you don't need
any extra dependencies.
On Wed, Mar 29, 2017 at 4:56 PM, Mark Nuttall [via Camel] <
ml-node+s465427n5796700h63@n5.nabble.com> wrote:
> 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 <
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=5796700&i=0>>
> wrote:
>
> > 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 <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5796700&i=1>> 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 <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5796700&i=2>> 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 <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5796700&i=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
> > >>> 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
> > >>
> >
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://camel.465427.n5.nabble.com/SEDA-vs-embedded-ActiveMQ-
> tp5796692p5796700.html
> To start a new topic under Camel - Users, email
> ml-node+s465427n465428h31@n5.nabble.com
> To unsubscribe from Camel - Users, click here
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=c291Y2lhbmNlLmVxZGFtLnJhc2h0aUBnbWFpbC5jb218NDY1NDI4fDE1MzI5MTE2NTY=>
> .
> NAML
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/SEDA-vs-embedded-ActiveMQ-tp5796692p5796701.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: SEDA vs embedded ActiveMQ
Posted by Mark Nuttall <mk...@gmail.com>.
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 <
quinn@pronoia-solutions.com> wrote:
> 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 <mk...@gmail.com> 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 <rm...@gmail.com> 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 <mk...@gmail.com>
> 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
> >>
>
>
Re: SEDA vs embedded ActiveMQ
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <mk...@gmail.com> 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 <rm...@gmail.com> 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 <mk...@gmail.com> 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
>>
Re: SEDA vs embedded ActiveMQ
Posted by Mark Nuttall <mk...@gmail.com>.
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 <rm...@gmail.com> 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 <mk...@gmail.com> 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
>
Re: SEDA vs embedded ActiveMQ
Posted by Muhzin <rm...@gmail.com>.
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 <mk...@gmail.com> 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