[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
- From: ryan@nardis.ca
- Date: Sat, 19 Jul 2014 04:28:42 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Back in June, Gerry replied to me privately. Copying his thoughts
here, with his permission:
On Sat, Jun 14, 2014 at 8:13 AM, Gerry Calderhead
<gerry@everythingsucks.co.uk> wrote:
> Hi,
>
> It's been a while since I looked at this - in fact since I originally
> reported it.
> In the end I concluded it was too much work for me to continue investigating
> and re-implemented autogroup using an external perl script
> and removed it from my build of openldap.
>
> My conclusion at the time, IIRC, was that the overlay architecture was a bit
> broken and needed a re-think, specifically to avoid the need to be reentrant
> - ultimately, by making the overlay CB's asynchronous.
>
> I think I had in mind something like:
> create a thread local holding a notification queue
> a _modify() call would add a notification to the queue for each overlay
> The stack would unwind to some point (perhaps overlay is wrapped for
> this?), and there the CBs would start to happen for overlays
> As the overlays do their writes more notifications are added the queue
> The cycle repeats until the overlays stop figging with stuff and the
> queue empties
>
> The reason for the thread local was to avoid changing the overlay API
>
> Even with this approach there is still the possibility to get overlays
> caught in an infinite loop - where overlay1 makes a change,
> triggers overlay2 which makes a change and triggers overlay1 and so on...