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