Tom Rutt wrote:
Sunil Kunisetty wrote:
>
> Tom,
>
> Here are the consolidated list of problems with this proposal.
Some
> of them have
> been already mentioned, just listing them again for completeness.
> Some of them
> are critical and some of them are minor:
>
First of all, I am proposing this syntax for discussion, to show how
we
could modify the syntax to make poll response more
I understand and hence listing the issues I can think of.
functional. I am not tied to this proposal strongly. However,
we have
to decided whether poll is useful without fault information
being present. The cost to make fault info present involves keeping
a
list of message ids for each fault code type which occurs, until
the group expires.
> Conceptual changes (major):
>
> 1. Changes in persistence model:
> 1. We now end
up persisting non-expired some faulty
>
messages. Note that messages that caused
>
PermanentProcessingFailures may or not be persisted in the
>
first place.
>
The persistence involves saving the fault code for messages which were
not delivered. The alternative, is to have polling which gives
no
That's correct. This will be a new requirement.
information about the faults which casse messages not to be delivered.
> 1. Definition
of MessageOrder and DuplicateElimination has to
>
change (slightly) since we persist faulty messages also.
>
So a duplicate message is deleted only if the earlier
>
message was not faulted. Something similar has to be said
>
for Message Ordering.
>
I do not understand. A faulted message is not delivered, and
that is
all that matter as far as duplicate elimination is concerned.
A duplicate is
not be delivered if the earlier message was delivrered.
The poll
reporting syntax has nothing to do with the definitions of
duplicate elimination. Same for message ordereing, do not deliver
if
the prior is not delivered.
A poll as such doesn't have effect on the DE and MO, however, persisting
the IDs for faulty messages has an effect. So, what I meant was:
1) Earlier, if we are just doing duplicate elimination, a check
for the msg Id
in the persistence store was a good enough
check to see a whether a
msg. was delivered or not. Now, that won't
be enough and we also need
to maintain the delivery status. A FaultCode
could be used as an
indicator that a Msg. was not delivered.
2) For message ordering, we need to clarify the group termination
and
status removal criteria whether the group
termination parameters
(IdleDuration and GroupExpiryTime) on a Fault
messages has
an effect or so.
Here is an example:
Msg1: groupId=1, SeqNo=1, groupExpiryTime
4.00 pm.
Msg2: groupId=1, SeqNo=2, groupExpiryTime
10.00 pm.
Assume Msg2 caused some fault and was not delivered,
so in that case
what shall be the group's expiry time, 4.00
pm or 10.00 pm?
Earlier, it was not an issue as we were not
persisting the msg2 and hence
it would be 4.00 pm in that case.
Now, we need to clarify one way or other.
> Conceptual changes (minor):
>
> 1. Poll response will now be different than
Callback and Response
> reply pattern responses. So implementation
logic to handle them
> will have to be different.
>
The semanitics of response reply is that it only holds the ack for
one
message. IT IS DIFFERENT semantically. The syntax allows
the response to carry multiple messages, however for Response reply
pattern only one message may be acked. The callback allows
multiple acks but only one fault to be reported. The new proposal
for
poll response allows multiple acks and multiple fault info to be reported.
While the semantics are different, they all were using the same Response
element and the logic of interpreting it would have been the
same.
Now we need different logic (read: code).
> 1. Have to be mentioned that only non-expired message
faults will
> be sent back.
>
agree
> 1. Have to be mentioned that not all non-expired
faulty message's
> faults can be sent back as some
messages can cause fatal errors
> (those that cause PermanentProcessingFailures
faults).
>
If the receiving rmp can send the fault on a response or a callback,
why
could it not send it on a poll response?
The difference is in the Response and Callback case, the Fault will
be
sent back immediately and hence will have an InvalidExpiryTime
fault.
Because for a Poll case as we plan to say that only non-expired
faults
(see the above bullet) will be sent back, InvalidExpiryTime faults
may be or may not be sent.
> Problems with the proposed schema (minor, can be fixed):
>
> 1. Both RefToMessageIds and RefToFaults doesn't
have minOccurs=0,
> so essentially you cannot send
either just one fault or one
> regular RefToMessageId. If you
add minOccurs=0 to both the
> subelements, then a PollResponse
could be empty. Schema
> validation could be difficult
in that case.
>
The intent is to allow zero or more fauld codes to be sent. For
each
fault code, there must be at least one message that had that fault.
I was referring to the top level (RefToMessageIds and RefToFaults)
elements.
Since they don't have minOccurs=0, a poll for even one message
MUST have
to carry both the elements, although the elements could be empty.
Ex: For a Poll response to a delivered messages.
<PollResponse>
<RefToMessageIds>
<SequenceNumberRange
from=1 to=1 />
</RefTiMessageIds>
<RefToFaults/>
</PollResponse>
For a Poll response with one fault
<PollResponse>
<RefToMessageIds />
<RefToFaults>
<FaultCode> .... </FaultCode>
...
</RefToFaults>
</PollResponse>
> 1. RefToFaults should not extend RmBaseType as only
top-level
> elements (Header elements) should
extend it. Sub-elements
> shouldn't extend it. Because
RefToFaults extends RmBaseType, it
> has soap:mustUnderstand=true
on a sub-element, which doesn't
> make sense.
>
I agree, i just cribbed together a schema since you asked for one.
This
is an easy fix, as you say.
> 1. If we have to go this route, it will be much
simpler to add an
> attribute (faultCode) to SequenceNumber
rather than add a new
> RefToFaults element.
>
> While we can still address all the above either explicitly saying
so
> in the specification,
> it will have a big impact on the schema and specification and
will
> delay the public draft
> atleast by a month. What concerns me more is why this issue
is being
> raised so
> late in the game, when we already decided not to have this
fault
> sending feature for polls
> long time back. I wish the issue was raised at that time only.
The issue has been raised, not by me but by Tony Graham, both at the
jan
f2f and on last week's call..
I did reply immediately to Tony's mail during that time that Poll
doesn't have that
capability.
The alternative resolution for this issue (other than enhancing the
schema) is for us to live with polling having no ability to report
fault
information.
> -Sunil
>
> Tom Rutt wrote:
>
>> These issues deal with the semantics of poll response for messages
which
>> were not delivered due to a fault
>>
>> Current semantics of returning fault are as follows:
>>
>> For resposne reply pattern a single message fault is returned in
the
>> response to the reliable request.
>>
>> For callback reply pattern, a single message fault is returned in
the
>> callback containing the Fault element.
>>
>> It is not clearly stated, but the receving RMP could batch a bunch
of
>> acks in a single callback message, but there is not way to do this
>> for faults.
>>
>> Currently there is not way to indicate in a response to a poll that
a
>> message was not delivered due to a fault. The response
to the
>> poll merely lists all message IDs in the poll range which were
>> delivered. Messages not in that list may be held, or may have
been not
>> delivered due to a fault condition.
>>
>> A fault element in a response to a poll, only indicates a problem
wiht
>> the poll request itself. It cannot be used to indicate a fault
on a
>> prior
>> reliable messasge request.
>>
>> The current Response syntax is as follows:
>>
>> <!--
>>
>> Response Header Type and it's elements
>>
>> -->
>> - <#> <xsd:complexType name="*ResponseType*">
>> - <#> <xsd:complexContent>
>> - <#> <xsd:extension base="*wsrm:RmBaseType*">
>> - <#> <xsd:sequence>
>>
<xsd:element name="*RefToGroupId*"
>> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>> </xsd:sequence>
>> </xsd:extension>
>> </xsd:complexContent>
>> </xsd:complexType>
>>
>> We could add a new element to the responst type as follows
>>
>> <xsd:complexType name="*ResponseType*">
>> - <#> <xsd:complexContent>
>> - <#> <xsd:extension base="*wsrm:RmBaseType*">
>> - <#> <xsd:sequence>
>>
<xsd:element name="*RefToGroupId*"
>> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>>
<xsd:element name="*RefToFaults*" type="*wsrm:FaultsRefType*"
>> maxOccurs="*unbounded*" />
>>
>> </xsd:sequence>
>> </xsd:extension>
>> </xsd:complexContent>
>> </xsd:complexType>
>>
>> <xsd:complexType name="*FaultsRefType*">
>> - <#> <xsd:complexContent>
>> - <#> <xsd:sequence>
>>
<xsd:element name="*FaultCode*" type="xsd:string"
>> maxOccurs="*1*" />
>>
<xsd:element name="*RefToGroupId*"
>> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>> </xsd:sequence>
>> </xsd:complexContent>
>> </xsd:complexType>
>>
>> An example of the structure of the RefToFaults element (repeated
here
>> twice) would be as follows
>>
>> <RefToFaults>
>>
>> <FaultCode>
processingError </FaultCode>
>>
>> <RefToGroupID>
... list of message ids in group a which had
>> processing error fault ... </RefToGroupID>
>>
<RefToGroupID> ... list of message ids , in group b which
>> had processing error fault ... </RefToGroupID>
>> </RefToFaults>
>>
>> <RefToFaults>
>>
>> <FaultCode>
BadHeader </FaultCode>
>>
>> <RefToGroupID
... list of message ids in group a which had
>> Bad header fault ... </RefToGroupID>
>>
>> </RefToFaults>
>>
>> The major problem with this is the requirmenet for the receiver
to
>> remember which fault codes arose for each non-delivered message.
>>
>> However, it would give full functionality to the poll response.
>>
>> Tom Rutt
>>
>> --
>>
>> ----------------------------------------------------
>> Tom Rutt
email: ;
>> Tel: +1 732 801 5744
Fax: +1 732 774 5133
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>>
--
----------------------------------------------------
Tom Rutt
email: ;
Tel: +1 732 801 5744
Fax: +1 732 774 5133
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
