Any issues with creating lots of short lived queues?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Any issues with creating lots of short lived queues?

Kevin Burton
Can you see any issue with creating queues and them reclaiming them in a
short window? I’d probably need to do this a few million times an hour.

PS. Sorry for all the small questions. I figure fit was easier this way
than explaining my larger design problem.

--

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>
Reply | Threaded
Open this post in threaded view
|

Re: Any issues with creating lots of short lived queues?

artnaseef
Yes.  Destination creation and removal has high overhead.  A few million times per hour - that's insane.

Maybe the problem would be better served by an XMPP messaging model (point-to-point or broadcast to a room of subscribers).  Or maybe zeromq.

Destinations are the core of ActiveMQ's activities, and as per the JMS spec, there are guarantees there related to them.  The brokers organize a lot of structure around destinations.
Reply | Threaded
Open this post in threaded view
|

Re: Any issues with creating lots of short lived queues?

Tim Bain
The only problem with asking the small questions instead of laying out the
architectural issue is that this feels like an XY Problem (
http://xyproblem.info/), so us answering the Ys may miss the chance to find
a better solution to the X.
On Feb 1, 2015 9:44 PM, "artnaseef" <[hidden email]> wrote:

> Yes.  Destination creation and removal has high overhead.  A few million
> times per hour - that's insane.
>
> Maybe the problem would be better served by an XMPP messaging model
> (point-to-point or broadcast to a room of subscribers).  Or maybe zeromq.
>
> Destinations are the core of ActiveMQ's activities, and as per the JMS
> spec,
> there are guarantees there related to them.  The brokers organize a lot of
> structure around destinations.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Any-issues-with-creating-lots-of-short-lived-queues-tp4690781p4690800.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Any issues with creating lots of short lived queues?

Kevin Burton
Yeah. I agree but it’s complicated :-P …there are a lot of requirements and
it would take 2-10 pages to write them up I think.

On Mon, Feb 2, 2015 at 5:49 AM, Tim Bain <[hidden email]> wrote:

> The only problem with asking the small questions instead of laying out the
> architectural issue is that this feels like an XY Problem (
> http://xyproblem.info/), so us answering the Ys may miss the chance to
> find
> a better solution to the X.
> On Feb 1, 2015 9:44 PM, "artnaseef" <[hidden email]> wrote:
>
> > Yes.  Destination creation and removal has high overhead.  A few million
> > times per hour - that's insane.
> >
> > Maybe the problem would be better served by an XMPP messaging model
> > (point-to-point or broadcast to a room of subscribers).  Or maybe zeromq.
> >
> > Destinations are the core of ActiveMQ's activities, and as per the JMS
> > spec,
> > there are guarantees there related to them.  The brokers organize a lot
> of
> > structure around destinations.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://activemq.2283324.n4.nabble.com/Any-issues-with-creating-lots-of-short-lived-queues-tp4690781p4690800.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.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>