Problem with async-echo test

[Stefan (metze) Metzmacher]

Hi Volker,

> On Wed, Jul 27, 2011 at 09:07:59PM +0200, Volker Lendecke wrote:
>>> This is really the proposed clean way for this problem?
>>
>> Just FYI: It does fix the problem, thanks a lot for the
>> quick response!
>>
>> It's just that I doubt this is the right place to fix it.
>> To me it is really surprising that the requests are
>> re-ordered on their way to the network, the necessity to run
>> tevent_loop_once until a cifs request shows up on the
>> cli_state is pretty surprising t me. We control everything
>> from the API callers to the socket calls, what we do not
>> control is the server side.  It is absolutely expected that
>> the server is allowed to re-arrange its replies. Why this is
>> allowed to happen within the libsmb and librpc code locally
>> that we control 100% is not really transparent to me.
>

Does the code in this patches also fix the problem for you
(attached and in this branch
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-tmp3)

> Question: I need to extend that test now and intermix rpc
> sleep requests with outstanding write&x and echo requests.


> Is there a way to make sure they are sent out to the wire in
> the order the caller does them, or does the design of the s3
> client library not allow this?

The smb layer should allow this, but the rpc layer doesn't
allow async parallel requests yet on a single transport (smb named pipe
or tcp).

What you could do is using multiple rpc connections over one
smb session, similar to winbindd. Then you can have multiple
outstanding rpc requests (but just not on the same named pipe).

My master3-tmp3 branch should allow this, but I haven't tested it
much yet, so please don't push it to master yet.

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/20110728/35a42bc6/attachment.pgp>