activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [Spam: 5.0] Evaluating Embedded ActiveMQ - questions
Date Tue, 06 Mar 2007 09:37:38 GMT
On 3/6/07, rbector <> wrote:
> Hello James
>    Thanks for your response. Please see below:
> > 1) We'd prefer to use the embedded version of the broker. All
> > communicating
> > applications would use the embedded broker so there would be no *server*
> > running. I've read that this Topology is supported by ActiveMQ. What are
> > the
> > downsides of using this topology ? The upsides to me are - higher
> > performance because of one less hop and less maintenance. Comments ?
> The main downside is managing persistent state. Using embedded brokers
> means each process has a bunch of persistent files and/or database. If
> you've tons of processes this becomes unwiedly soon, so running
> separate brokers is often easier.
> I am still trying to understand why this is hard to manage if you are using
> a database.
> Cant all the participating applications use the same database ? What exactly
> is
> the management overhead there ?

Each broker requires its own database. Also if you want high
performance, each broker has its own journal files. (For real high
performance in version 5.x you'd use the pure file persistence

> > 2) I would like to have the ability to create topics such that messages on
> > them are never deleted. Essentially, any consumer could attach to the
> > topic
> > any point in time (even 30 days after the topic was created) and receive
> > older messages (Ideally - it should have the choice to start receiving
> > messages from a certain point in time in the past or from a certain ID).
> > The
> > idea behind this approach is that consumers are more decoupled. They could
> > process some messages, checkpoint them internally and go away and come
> > back
> > later.  I would like to try to understand if this is directly or
> > indirectly
> > supported in ActiveMQ (or other JAVA based messaging systems that people
> > know of)
> Its generally not supported by JMS but we've some extensions you can
> use to do this kind of thing...
> thanks for pointing that out. I see that description as being quite sketchy.
> I dont know how well it works if there could be *tens of thousands* of such
> messages
> enqueued (persistent) while the receiver is gone.

BTW I'm not aware of any other MOM which supports retroactive topic subscribers.

The feature was mostly written for non-persistent messaging,
particularly for things like last image caching or keeping around a
buffer so a client could switch brokers without loosing messages etc.
There are hooks to plugin in any kind of persistence/query mechanism
you wish.

Probably a better idea is to tweak the durable topic region for your
needs; where every message is always persisted whether there is a
subscriber or not and you add retroactive-subscription support to
durable topics (which I don't think is implemented yet). Then you can
configure when the database cleanup occurs to purge unwanted messages
from the database to your exact needs

We welcome patches!


View raw message