Problem with async-echo test

[Stefan (metze) Metzmacher]

Am 27.07.2011 18:19, schrieb Volker Lendecke:
> On Wed, Jul 27, 2011 at 10:57:42AM +0200, Volker Lendecke wrote:
>> 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.
>>
>> 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.
> 
> A little more analysis: To me it seems that it has to do
> with the double-queueing in the following way: The
> tstream_writev_queue_send call in rpc_tstream_trans_send
> triggers a tevent_schedule_immediate because the queue is
> not empty. Then the cli_smb_send calls come in, also
> triggering the schedule_immediates. There is a single
> immediate dlist in the tevent_context, all
> schedule_immediate calls are added to the end of the list.
> The first one is the one from tstream_writev_queue_send (the
> rpc call). This is called, converting the rpc tstream call
> into a smb level call, which triggers another
> schedule_immediate. Because it comes after the cli_send_smb
> calls from cli_echo_send and so on it has to line up after
> all the other calls.

Yes, that's what's happening.

See my other mail for a proposed fix for this specific test.

metze

-------------- 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/3ac5fa86/attachment.pgp>