[PATCH] restructure messaging
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 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
> queuing things forever, maybe a one-day timeout is appropriate for
> AD DC? What happens if it blocks for full 24 hours? Do the clients
> 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
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
I'll keep thinking about what semantics we need (compared with what we
I hope this helps,
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
More information about the samba-technical