OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[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]