Re: AW: [ws-rx-implement] Interop doc scenario 1.3

[Doug Davis <dug@us.ibm.com>]

Stefan,
  there are really a couple of
different issues here:
1 - when does the RMD consider a message
received?  For the most part this is implementation specific.  For
example, some may consider it 'received' before it is persisted and some
may only consider it received 'after' it is persisted.  This is a
detail left out of the spec.  But I would hope this would not be dependent
on the DA being used - but I guess there's nothing in the spec preventing
someone from doing it (like the FIFO queue thing you mentioned) but to
be honest I don't think that's a good solution (see next bullet).
2 - what is sent back in the SeqAck
header.  IMO, this must include all received messages regardless of
whether or not the RMD is blocking, waiting for a lower numbered one.  This
is important because I doubt you want the RMS to resend message #3 over
and over just because message #2 hasn't arrived/been acked.  Again,
there's nothing in the spec preventing you from not acking message #3 but
I wouldn't consider that to be an optimal solution.

So, in scenario 1.3, after messages
1 and 3 are sent (and arrive at the RMD), if the RMS sends an AckReq message
to the RMD, the SeqAck header that gets returned MUST have messages 1 and
3 in it.   BTW - on the call this week we decided to go with option
#2 - wait a certain amount of time and then send a Close().  we're
assuming that if we wait (say 15 seconds or so), then 1 and 3 should have
arrvied by then and the SeqAck we get back on the CloseResponse should
contain 1 and 3.

thanks,
-Doug

"Rossmanith, Stefan" <stefan.rossmanith@sap.com>

03/01/2006 02:29 PM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	<ws-rx-implement@lists.oasis-open.org>
Subject	AW: [ws-rx-implement] Interop doc scenario 1.3

Hi Doug,
does WS-RX specifiy that an ack
must be sent back after the message was received (and stored) successfully
or after predecessor messages were received, too? As far as I know the
spec does not say anything about this.
So one implementation (A) could
send an ack for a given message not before the predecessor messages were
received and another implementation (B) could send the ack after the message
independent of in-order criteria was successfully received.
In this case (A)  acks message
#1 only and (B) #1 and #3 if we use solution 3 and if my above assumptions
are correct.
 
Do we want to have the same test
result concerning acks independent of (A) and (B)? Is this the aim of this
automated test case?
If my assumptions are correct
this could be difficult for 1, 2 and 3...
 
A reason for implementing (A)
could be to use a protocol on top of WS-RM for linking of sequences. In
this case e.g. an ack should not be sent back before the message was inserted
into a FIFO queue in the correct order.
 
Regards,
Stefan

---

Von: Doug Davis [mailto:dug@us.ibm.com]
Gesendet: Dienstag, 28. Februar 2006 18:29
An: ws-rx-implement@lists.oasis-open.org
Betreff: [ws-rx-implement] Interop doc scenario 1.3


In the scenario doc for 1.3 we close down the sequence after messages 1
and 3 were acked.  There's a problem here.  Depending on how
the incoming message is sent, and depending on the implementation choices,
message #3 may or may not ever get acked.  Its possible that the RMD
could block on processing of message #3 until message #2 arrives.  This
is because, even though its a one-way a Fault could still be generated
and would need to flow back on the http response flow - hence an implementation
may choose to block waiting until it knows for sure that no fault needs
to go back.  This then gets into the entire anon-replyTo issue - which
we don't want to get into.  Therefore I see a couple of options:
1 - send a close after just #1 is acked 
2 - send a close after a certain amount of time 
3 - assume everyone will send an independent AckRequested message that
will then allow the ack for msg #3 to flow back. 

I can go with any of these.  Thoughts? others?

thanks, 
-Doug