New issue - WS-AT: Invalid state inappropriate response to orphaned volatile participants

["Peter Furniss" <peter.furniss@erebor.co.uk>]

Issue name -- WS-AT: Invalid state inappropriate response to orphaned volatile participants

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.

 

The issues coordinators will notify the list when that has occurred.

 

Target document and draft:

 

Protocol:  WS-AT Volatile 2PC

 

Artifact:  spec

 

Draft:

 

AT spec cd 1

 

Link to the document referenced:

 

http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-spec-cd-01.pdf

 

Section and PDF line number:

 

section 10, lines 503/505 tables rows Prepared, Relay, column None

 

Issue type:

 

Design

 

Related issues:

 

New issue: Coordinator should not distinguish protocol of orphaned participants

 

Issue Description:

 

The use of Invalid State as the response to a Prepared or Replay received from a participant that had a (forgotten) volatile registration is inconsistent with the definition of Invalid State in WS-Coordination and requires special processing by implementations to handle this non-fault fault.

 

Issue Details

 

Background - see separate issue : Coordinator should not distinguish protocol of orphaned participants

 

The defined meaning of InvalidState in WS-Coordination is "This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault has received a message that is not valid for its current state. This is an unrecoverable condition."

 

Occurence of InvalidState according to this definition, and in all its other occurrences in the state tables for WS-AT or WS-BA imply that one or other of the implementations is bugged. It is to be expected that implementations would report such a fault conspicuously.

 

This is an inappropriate message in this instance. The meaning the coordinator needs to send to the participant is something like: "Legitimate message received, but transaction outcome is unknown: I can't help you".  Since the volatile participant, by definition, doesn't care very much, implementations will not want to contaminate their error logs with reporting these occurrences, which can occur between fully correct implementations. They will either have to insert special code to identify this circumstance or annoy their users.

 

Proposed resolution

 

Use a new message, as proposed for issue WS-AT: Coordinator should not distinguish protocol of orphaned participants