James.Strachan wrote: > > On 3/6/07, rbector <[EMAIL PROTECTED]> wrote: > >> 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 > option). > > > That is quite interesting. I can see each broker requiring its on tables. > In our system, we'd probably have 5-8 applications so I think the > management is still less of a concern. Performance is definitely a bigger > concern > >> > 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. > > BTW I'm not aware of any other MOM which supports retroactive topic > subscribers. > > thanks > > 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 > > That seems to be the way to go. I've been researching java based message > brokers last couple days and I am somewhat disappointed so far (in one of > my previous jobs, I was responsible for developing a linux/c/kernel based > high performance message broker which provided all of these > features/semantics and more) in what I've found. I'd like a > high-performance, serverless option to generate, store and deliver events. > ActiveMQ is probably the closest thing to what we need. So we may actually > go ahead and enhance it for our needs, as you pointed out. > > Thanks much for your feedback again. > > - Rajeev > > > We welcome patches! > http://activemq.apache.org/contributing.html > -- > > James > ------- > http://radio.weblogs.com/0112098/ > >
-- View this message in context: http://www.nabble.com/Evaluating-Embedded-ActiveMQ---questions-tf3350861s2354.html#a9344616 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
