Problem with async-echo test

[Stefan (metze) Metzmacher]

Am 27.07.2011 19:02, schrieb simo:
> On Wed, 2011-07-27 at 18:19 +0200, Volker Lendecke wrote:
>> 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.
> 
> Shouldn't immediate calls use a LIFO paradigm instead of a FIFO one ?
> At least that would make more sense to me.

Why? then the first one could be deadlocked by the others.

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/795ac2c1/attachment.pgp>