[BYTEIO-WG] ByteIO Interoperability Fiesta

[Michel Drescher]

Mark Morgan wrote:
> Correct me if I'm wrong Michel, but isn't it the case that there are
> test cases in the interop fest. which require you to delete a resource
> and then send another message to that resource to verify that it was
> deleted (by virtue of the fact that the container issues a fault)? 

I would not know which one that would be. All but one test cases test ByteIO
operations, whether Random ByteIO or Streamable ByteIO. The only external
operation that is tested is the GetResourceProperty operation.

To my knowledge of the document all test cases MUST follow the pattern:
1. Create resource (through the factory)
2. Execute the test case
3. Delete resource (through the factory)

So if you would want to test, say "Read(I)" and "Read (II)" in one test
client invocation, then the overall sequence would look like this:

1. Create resource "a" (through the factory)
2. Execute test case "read (I)" on resource "a"
3. Delete resource "a" (through the factory)
4. Create resource "b" (through the factory)
2. Execute test case "read (I)" on resource "b"
3. Delete resource "b" (through the factory)

The idea is that, whenever you execute whichever test case, you always can
expect a resource with a particular layout/contents on the back end. THe
fact that the write, append and truncAppend test cases invoke the read
operation to test whether the file contents has changed as expected is an
implementation detail as those operation invocations all fall under the
"Execute the test case" sequence.

> If so, then the race condition in question affects the clients of the
> interop. fest. 

If it were so then yes, you would have a point. But, as to my knowledge, the
 interop testing spec never meant to use one resource for all tests. They
were all meant to be executed on their own individual resources.

> It isn't fair to say that an implementation MUST
> guarantee monitor semantics on their resources and without a result
> value from the service indicating success of the delete operation, there
> is no way to guarantee the order of operations on the service (even
> though by virtue of the fact that the two messages in question are
> coming from the same client, and the nature of TCP/IP I agree that the
> messages WILL in fact arrive in the correct order, I still don't believe
> that its correct to assume that a service chooses to handle two
> asynchronous messages in the same order that they arrived in unless the
> client guarantees it by blocking on results).

The design of the deleteResource operation was never meant for the server
side to guarantee anything. It was designed so that the client tells the
server "guy, I'm done with this resource, ditch it, I am interested no more
in this resource". The implicit obligation on the client thus is to never
ever consider that resource to be extant anymore. The interop testing spec
ensures that by stating that, for each test case described, the client MUST
invoke the factory's "createResource" operation first, then, following the
test case description, invoke some RandomByteIO or StreamableByteIO
operations on that EPR, and then destroy that resource (invalidating the
current EPR) afterwards as some means of cleanup.

For example, in our implementation, our RandomByteIO resources do have a
lifetime of one minute. After that, the resources expire automatically and
are cleaned up. So in essence I do not need the deleteResource operation at
all. It is there to let service implementations know when they can clean up
an interop resource because it is no longer needed anymore.

In our implementation, to avoid race conditions, we do two things:
- Use a Java mutex lock to synchronize key parts of our code
- When we receive the command to delete a resource, whether through the
  interop factory operation, expired lifetime infrastructure, or other
  means, the first thing we do is to disconnect the resource from any
  messaging connector. In effect our messaging connector then considers
  the resource nonexistant and sends back a fault. The fact that this fault
  is not the ResourceUnknownFault is our problem - a problem that I expect
  any WS hosting environment has. I know this for a fact for JAX-WS and
  Axis, unless you hack the hosting environment itself.
- The code part that disconnects the resource from and messaging connector
  is guarded by the same Java synchronize() lock as any other vital part of
  our implementation.

Cheers,
Michel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/byteio-wg/attachments/20070724/439c58fc/attachment.pgp