[BYTEIO-WG] ByteIO Interoperability Fiesta

[Mark Morgan]

My apologies folks,

I misunderstood what my developer was telling me.  Its completely my
fault and it turns out that this race condition is not actually a
problem.  Since we never test the deleted resources, there isn't an
issue with them.

-Mark

> -----Original Message-----
> From: byteio-wg-bounces at ogf.org [mailto:byteio-wg-bounces at ogf.org] On Behalf
> Of Mark Morgan
> Sent: Tuesday, July 24, 2007 9:59 AM
> Cc: byteio-wg at ggf.org
> Subject: Re: [BYTEIO-WG] ByteIO Interoperability Fiesta
> 
> 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)?  If
> so, then the race condition in question affects the clients of the
> interop. fest.  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).
> 
> -Mark
> 
> On Tue, 2007-07-24 at 14:45 +0100, Michel Drescher wrote:
> > Hi,
> > 
> > Mark Morgan wrote:
> > > The race condition is that a multi-threaded server may not finish
> destroying
> > > a resource before the client sends the next request to the resource.  In
> our
> > > code, if our client has:
> > > 	send_op()
> > > 	destroy()
> > > 	send_op()
> > > The second send_op() succeeds (whereas it should fail) unless we pause
> > > between the destroy and the send_op.  The reason for this (I believe) is
> > > that destroy in Genesis II is slightly heavy-weight in that it needs to
> > > (potentially) send out notifications and clean up WS-Naming resolvers.
> > 
> > But if I understand that right, the race condition is in your code (or
> > hosting environment) rather in the messaging itself?
> > 
> > Cheers,
> > Michel
> > 
> > 
> 
> --
>   byteio-wg mailing list
>   byteio-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/byteio-wg