RE: Issue 6432: updated proposal

Bob,
 
I'll give it a shot. Corret me if I'm wrong. Let's assume MC
(non-addressable EPR) and Push (addressable EPR) operate under the same
conditions:
1) both use queues for in-order delivery
2) both deliver individual messages (not batching)
3) the queues are maintained by the event source
 
On the event source side:
Push mode:
the event source enques the message if the queue has space
the event source deques the message if the queue is not empty
the queue length depends on the rates of event arrival and the deque
activities
 
MC mode:
the event source enques the message if the queue has space
the event souce deques the message if the queue is not empty AND there
is a MC request
the queue length depends on the rates of event arrival and the MC
requests
 
On the event sink side:
Push mode:
the event subscriber subscribes to the event source
the event sink receives notifications
 
MC mode:
the event subscriber subscribes to the event source
the event subscriber notifies the event sink the subscdription is
accepted (this is optional to trigger the poll)
the event sink polls the notifications based on the MC pending flag or
at some interval
the event sink receives notfications
 
As the result, we need to consider different factors in queue design on
the event source side. Notice that the event source has no knowledge of
MC request rate, but it can control deque to some extent (network
latency is an unknown factors in both modes).
Similarly, the factors that influence the timing of notifications are
different on the event sink side. In MC mode, the event sink has to
choose a poll interval which is not needed in the Push mode.
We can reduce the timing factors by using more connection resources in
MC mode (as describe in my previous email). But that introcues another
difference.
 
thanks,
Li
 
-----Original Message-----
From: Bob Freund [mailto:bob.freund@hitachisoftware.com] 
Sent: Monday, March 23, 2009 6:14 PM
To: Li, Li (Li)
Cc: Doug Davis; public-ws-resource-access@w3.org; Chou, Wu (Wu)
Subject: Re: Issue 6432: updated proposal



Li and Doug (and others, of course) 
Is there a set of requirements for an acceptable queueing mechanism?
Is it that there are queuing behavior issues that are distinct from the
non-addressable client requirement issues?
What sort of behavior is required?
Does MC meet those requirements or not?
thanks
-bob

On Mar 23, 2009, at 5:48 PM, Li, Li (Li) wrote:


Doug,
That is a useful feature that can eliminate poll intervals if the events
arrive at a steady rate relative to the poll rate, i.e. when you poll
the i-th notification, the (i+k)-th notification already arrived to make
pending=true. For an event series that does not behave this way, when
does the next poll happen if a poll returns pending=false? If we poll
immediately to ignore the flag, the next event may not arrive for
sometime (so we waste some connection); if we wait as implied by the MC
spec (to save connection), we increase the chance of delay. 
 
 
thanks,
 
Li

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, March 23, 2009 4:30 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject: RE: Issue 6432: updated proposal



Li, 
  if you look at the MC spec there's a "MessagePending" header that can
be used to indicate that the event sink should poll immediately when
more messages are pending.   

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 



"Li, Li (Li)" <lli5@avaya.com> 


03/23/2009 03:42 PM 


To
Doug Davis/Raleigh/IBM@IBMUS 	

cc
<public-ws-resource-access@w3.org>,
<public-ws-resource-access-request@w3.org>, "Chou, Wu (Wu)"
<wuchou@avaya.com> 	

Subject
RE: Issue 6432: updated proposal	

		




Doug, 
  
if so, that means only in the batch format can mc support timely
delivery of notifications without the added latency compared to the
"unsolicited push" mode. 
  
this would work like this: 
1) mc request (uuid=xyz) 
2) subscribe (notifyto=xyz, format=batch) 
3) all notifications sent using the same mc connection, until 
4) the subscription terminates 
  
i called mc request before subscribe to eleminate the potential delay
caused by the mc request. 
  
In a non-batch format, the sink polls the event source at some interval,
so there is a added delay of 
T(poll interval) + T(sending mc request) + T(processing of mc request) 
  
To reduce the delay, we can make "poll interval" as small as possible
(in fact we can make it zero using the batch format), but the tradeoff
is we occupy more connection resources on the event source. 
For this reason, i'm hesitating to merge these two approaches under the
"push" mode. 
  
Thanks. 
  
-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, March 23, 2009 2:50 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject: RE: Issue 6432: updated proposal


Right -that's batching or box-carring.  And if we want to support that I
think we need to define a new Format so it can be used regardless of
whether we're pushing or pulling notifications. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 


"Li, Li (Li)" <lli5@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 


03/23/2009 02:46 PM 




To
Doug Davis/Raleigh/IBM@IBMUS 	

cc
<public-ws-resource-access@w3.org>,
<public-ws-resource-access-request@w3.org>, "Chou, Wu (Wu)"
<wuchou@avaya.com> 	

Subject
RE: Issue 6432: updated proposal	


		





Doug, 
 
I meant in one subscription created by mc, is it possible that one mc
request will pull back mutiple queued messages, or is it always one mc
request for one message. 
Suppose there are two messages queued for a subscription, in the first
case we have these messages: 
 
mc request 
msg1 
msg2 
 
in the second case, we can only have 
mc request 
msg1 
mc request 
msg2 
 
thanks. 
 
-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, March 23, 2009 1:33 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org; Chou, Wu (Wu)
Subject: Re: Issue 6432: updated proposal


It depends on what you mean by multiple messages.  If you mean
"batching" then sure that can be done but since this could be wanted
even for Push style I think that's best left for the new Format element.
However, this can be very complicated though since some Notifications
could generate faults and its not clear what the processing model would
be.  If you mean "pulling from multiple subscriptions" then yes - you
can do this optimization by using the same MCanonURI in multiple
NotifyTo EPRs. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 

"Li Li" <lli5@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 


03/23/2009 12:34 PM 




To
<public-ws-resource-access@w3.org> 	

cc
"Chou, Wu \(Wu\)" <wuchou@exchange.avaya.com> 	

Subject
Re: Issue 6432: updated proposal	




		






Doug,

The MakeConnection standard suggests that the event sink initiates a
connection for each message. Is it possible that the event sink
initiates a
connection for multiple messages?