[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsn] Pull-type notification
I think we should avoid going down the route of defining a fully-featured Queue service. If and when someone defines one, then it could be subscribed into a Notification Producer using the existing push subscribe mechanism. For now we should concentrate on a basic pull delivery mechanism. A traditional FIFO queue provides a good solution for scenarios which require lossless ordered durable delivery. In this model getMessages(40) would return the 40 oldest messages in their original order. Of course there are scenarios where the consumer just wants to sample the subscription periodically and is not interested in receiving a lot of old messages, and I'm guessing that that was what is behind William's newest/clean proposal. We are going to need a buffer size set when the pull subscription is established (you can't rely on the consumer being timely about pulling messages) and have the subscription discard messages in an oldest-first order when the buffer is exceeded. So one way of addressing the scenario is simply to establish the subscription with a buffer size of 40, and then do getMessages(40) - this way you know that you are going to get the most recent message. The question then becomes whether we need additional variants, such as getMessages(all), and getMessagesNewest(n). In any case, I'm not sure we need to provide options that sort the n messages in a batch into anything other than their original order. Peter Niblett "Rick Cobb" <rcobb@KnowNow.co m> To Matthew I Roberts/UK/IBM@IBMGB, 10/02/2005 16:39 "Vambenepe, William N" <vbp@hp.com>, "wsn-oasis" <wsn@lists.oasis-open.org> cc Subject RE: [wsn] Pull-type notification I mostly agree with Matt's suggestions, however... > A second issue is whether GetMessages(40) should return the 40 oldest > messages (traditional FIFO queue) or the 40 newest messages > (FILO, which is > your proposal). I would prefer a traditional FIFO queue so > that we get the > 40 oldest messages (with no clean afterwards) as this > provides the lossless > durable delivery of existing messaging systems like JMS. If a > vendor wished > to implement the get-with-clean or FILO behaviours you > suggest I think it > should be on the basis of a policy statement. Note that > get-with-clean and > FILO (get newest) should probably always be combined, since > not doing so > results in shuffling the messages into a different order. I don't necessarily agree with this advice; for example, KnowNow supports cursor-like access (with both back and next) into our similar functionality, so FILO does not necessarily imply get-with-clean. This is particularly useful for consumers that are monitoring the actions of other consumers. -- ReC
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]