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 ?


> 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...

http://activemq.apache.org/subscription-recovery-policy.html


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.


> 3) If there are n consumers interested in a certain topic, some of the
> consumers may be away when messages on that topic are published. Whats the
> behavior of ActiveMQ in such a scenario ?  Is the subscription information
> maintained on a persistent basis (we'd like it to be).  (This is also in
> the
> context of embedded broker - the broker is embedded inside the
> producers/consumers)

It depends if you are using a durable topic consumer or not. If you
are, then yes it is. Otherwise no :).


ok. thats good to know.

Thanks
- Rajeev
-- 

James
-------
http://radio.weblogs.com/0112098/



-- 
View this message in context: 
http://www.nabble.com/Evaluating-Embedded-ActiveMQ---questions-tf3350861s2354.html#a9324107
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to