activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbector <bector.onl...@gmail.com>
Subject Re: [Spam: 5.0] Evaluating Embedded ActiveMQ - questions
Date Wed, 07 Mar 2007 00:44:12 GMT


James.Strachan wrote:
> 
> On 3/6/07, rbector <bector.online@gmail.com> 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.


Mime
View raw message