activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <bur...@spinn3r.com>
Subject Re: Proof that a lock GCing inactive destinations cause ActiveMQ to halt consumers and producers and DoS the broker
Date Mon, 09 Feb 2015 17:38:43 GMT
Well initially I didn’t think that just GCing the destinations would be a
problem.

One of the key features of using destinations is that I can peek at the
queues and look at their depth via JMX.

This will let me know if we’re crawling an IP too hard or falling behind on
our crawl.

With message groups I would lose that feature.

Using queues also allows me to browse them to see what is enqueued there
which is somewhat nice.

Also, by definition some of my consumers are slow.  So I’m not sure if
there would be performance implications with slow consumers.

I’ll definitely have to investigate more though.

On Mon, Feb 9, 2015 at 1:20 AM, Tim Bain <tbain@alumni.duke.edu> wrote:

> Kevin, have you considered using message groups, with one group per IP?
> They'll guarantee in-order delivery of your messages to a single consumer,
> which will let you throttle per IP.  You could only have one consumer per
> IP (I think, though maybe there's a way to have more and I don't know about
> it), but otherwise it seems to match your use case pretty well.  Is there
> something obvious I'm not thinking of that prevents you from using them?
> On Feb 9, 2015 12:46 AM, "Kevin Burton" <burton@spinn3r.com> wrote:
>
> > On Sun, Feb 8, 2015 at 5:59 PM, James Carman <james@carmanconsulting.com
> >
> > wrote:
> >
> > > Well, having "real" destinations come and go that quickly is definitely
> > not
> > > a typical use case.
> >
> >
> >
> > Agreed!
> >
> >
> > > Admittedly, I have not been following the conversation
> > > that closely, but you do seem to have done your homework.  I assume
> > > temporary destinations wouldn't suit your needs.
> >
> >
> > Not really unfortunately.
> >
> >
> > > Have you considered
> > > something like Akka?
> >
> >
> > I’ve looked at Akka but up until this point ActiveMQ seemed ideal.
> >
> >
> > > If you have this kind of throughput, do you really
> > > need persistence?  Is each message a precious commodity or is your
> > > application just extremely chatty?
> >
> >
> > Well the advantage of persistenxw, in theory, is that if we have an
> outage,
> > we can instantly recover from it without adding any latency to messages.
> >
> > However, it might be that I can go with all in -memory if we can rebuild
> > the queue within 5 minutes.  I’m totally fine with that.
> >
> > This is my mitigation plan now actually.
> >
> > I’m going to be running with an in-memory broker and then attempting to
> > rebuild the queue as quickly as possible.
> >
> >
> > > I'll try to dig through the
> > > conversation...
> > >
> >
> > Appreciate the feedback.!
> >
> > --
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > <https://plus.google.com/102718274791889610666/posts>
> > <http://spinn3r.com>
> >
>



-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>
<http://spinn3r.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message