Re: [BYTEIO-WG] ByteIO Interoperability Fiesta
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
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
participants (2)
-
Mark Morgan
-
Michel Drescher