[PATCH] restructure messaging

Andrew Bartlett abartlet at samba.org
Mon Oct 10 21:34:52 UTC 2016


On Mon, 2016-10-10 at 15:58 +0200, Volker Lendecke wrote:
> Andrew Bartlett <abartlet at samba.org> writes:
> 
> > On Mon, 2016-10-03 at 19:53 +0200, Volker Lendecke wrote:
> > Great, that should be enough.  Does that include in the single-
> > process
> > case?  
> 
> Yes.
> 
> > Yes and No.  Currently our code can get stuck for that long and
> > longer
> > blocked with the transaction lock held in the client-side of
> > replication.  That is a serious issue we are working on, as you can
> > imagine it creates pretty serious issues. 
> 
> What semantics does the AD controller need for messaging? Queue
> indefinitely? Set the timeout to an hour or a day? I feel a bit
> uneasy
> queuing things forever, maybe a one-day timeout is appropriate for
> the
> AD DC? What happens if it blocks for full 24 hours? Do the clients
> work
> fine with that?
> 
> > Bugs aside, the main use case we have that can wait for minutes or
> > hours is waiting for replication to complete, but that isn't meant
> > to
> > be blocking, but a very long time before the reply, and I think
> > that is
> > quite different.
> 
> Do you expect 24 hours to be a reasonable timeout for replication to
> complete? I want *SOME* timeout, I don't want things to pile up
> indefinitely.

For the 'waiting for a reply' case, the timeout waiting for the reply
just needs to be whatever the IRPC layer gets from the binding handle.
 The caller can control that. 

For the 'waiting to send' case, then the previous semantics were that a
message would generally send without delay (as it was using unconnected
unix dgram messaging), and be in the kernel buffer until read by the
same process or another.  As long as the unblocked case hasn't changed,
and the complex case only kicks in when that blocks, then I guess we
are OK. 

I'll keep thinking about what semantics we need (compared with what we
have had).

I hope this helps,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba







More information about the samba-technical mailing list