Problem with async-echo test

[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.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen