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.