[PATCH] restructure messaging

Volker Lendecke vl at samba.org
Mon Oct 3 17:53:13 UTC 2016

Andrew Bartlett <abartlet at samba.org> writes:

> For "[PATCH 20/30] messages_dgm: Drop a segment if we can't ship it for
> 60 seconds" does this impact on the IRPC use case?  Under what
> situation would this occur?

It happens when the receiver is so blocked that it won't pick up
anything from its socket. We have to protect ourselves against this
somehow. Imagine someone sends a SIGSTOP to notifyd. Right now this will
create a nice memory leak without bounds.

> I ask because it is quite possible that we might be in a replication-
> induced transaction for more than 60 seconds with the current code. 

If the sending process has already handed this over to the kernel, it
will arrive. You could argue that the DC needs more time, but I looked
at it from an SMB perspective: If there is something waiting for
anything for more than 60 seconds, the client will usually be very, very

Is it a legitimate use case that something takes more than 60 seconds?
The alternative would be to block the sender, but this might have
negative impact on client interaction.

Maybe we need to have two messaging subsystems again: One for AD and one
for SMB. AD has legitimate use cases where everything can block for
minutes or hours, SMB can not live with that.

Was it a mistake to unify the messaging subsystems?

> Can you add a variation on "Subject: [PATCH 16/30] messaging: add an
> overflow test" that confirms that all the messages are picked up?

I'll try.

> It would also be really useful to have a unit test for the fire-and-
> forget use of imessaging and IRPC used in ridalloc_poke_rid_manager(),
> auth_sam_trigger_repl_secret() and notify_dns dns_notify_dnssrv_send()
> because these seem to be part of our current problems.  Testing those
> for overflow and normal moves in self-handled, self-handled-but-in-
> another-loop and other-process-blocked states might move this from
> 'reproduce in a 4 hour autobuild' to 'debug in a unit test'.  

Sorry, I won't be able to do that. Please drop the patchset if this is a
prerequisite for acceptance.


More information about the samba-technical mailing list