Problem with async-echo test

[Stefan (metze) Metzmacher]

Hi Volker,

> Running the async-echo smbtorture3 test I came across a
> problem with the new dcerpc client libraries. That test
> sends a dcerpc_echo_TestSleep_send and then after that some
> cli_write_andx and cli_echo calls with the intention to put
> the server to sleep and walking the async echo responder.
> This does not work anymore, because the RPC request is only
> sent out to the network after the cli_echo and cli_write&x
> calls have been sent out. My impression is that this comes
> via double-queueing via the tstream layer in the rpc
> routines, but this impression might be wrong. I know this
> used to work at some point. See the attached network trace
> for the problem.

Yes, I guess that's exactly what happens here.

> I know so far we have not given guarantees about the
> ordering of requests in the async architecture, but my
> assumption so far was that we maintain the ordering between
> requests being sent to the smb client connection. If we now
> have the client libraries freely re-order requests, we need
> to augment them with something like barriers or so.

We just keep make sure the ordering is correct for one connection
layer.

If we want to do testing of specific ordering we need to do some
extra work.

I'd propose the attached fix.

metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-test_async_echo-unsure-the-desired-smb-message-se.patch
Type: application/mbox
Size: 1350 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110727/6a433231/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110727/6a433231/attachment.pgp>