activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fateev, Maxim" <fat...@amazon.com>
Subject RE: Paging support
Date Tue, 05 Sep 2006 20:18:05 GMT
>Messages are always put into storage - but they are additionally pushed to subscribers
for dispatching. I was going to implement a mixed approach - where consumers that can keep
up with the producer will not be impeded by waiting for a poll, but slower/non-active consumers
would ultimately rely on a poll from the store.
My view is that this "pushing" functionality should be hidden behind MessageStore API. CachingMessageStore
could be created that would keep messages for fast consumers in memory delegating other requests
to another permanent MessageStore. Having two separate dispatching code paths complicates
code. Another problem with direct dispatch is that in case of synchronous dispatch producer
performance directly affected by performance of consumer. I don't think that it is really
a good idea to have receiving socket thread perform write to a consumer socket directly.

>Yes - am changing - so the PendingMessageCursor can in effect ignore new messages from
a producer if it is full - or the usage manager has reached it's limit - and poll for them
later.
It is an example of two code paths. Only polling part would be required if you eliminate pushing
part.

>> 3. getNextMessage(...) should block if there are no messages in a 
>> queue. Otherwise it would require busy polling.
>depends on the implementation - more messages available can be triggered from producer
etc - providing the PendingMessageCursor is intialized with state and maintains it.
Again blocking getNextMessage() would be much more simple if pushing part is eliminated.

>> 4. I'm not sure about semantic of getNextMessage(...,
>> RecoveryListener) API. Will it create a thread per request? Will 
>> single blocked listener block the whole queue? I think "List 
>> getNextMessage(..., int count)" would have cleaner semantic.
>I think a Listener allows for more flexibility - in allowing the PendingMessageCursor
to stop a request if the usage memory is at its limit for example
I'm not sure why it has more flexibility. In case of blocking get... call you have the same
flexibility but more simple threading. For example you just don't call getNextMessage if the
usage memory is at its limit. RecoveryListener would require additional thread for every consumer
which doesn't scale.
BTW do you plan to have RecoveryListener per queue consumer or single one for the whole queue?

>Difficult call - I'm trying not to change the existing code too much
>- as I know there's been alot of bug fixes in the PrefetchSubscription/DurableTopicSubscriber
etc.  code, for timing issues, transactions etc - I'm >>tempted not to loose that if
possible :)
You can create different destination implementation that still uses existing Subscription
framework but relies on new MessageStore API. I have an example of such code on my desktop.

Mime
View raw message