[SSSD] ELAPI fundamental architectural issue

Simo Sorce ssorce at redhat.com
Fri Nov 20 18:06:55 UTC 2009


On Fri, 2009-11-20 at 12:50 -0500, Dmitri Pal wrote:
> b) Hold the events in queue inside ELAPI dispatcher and let them go
> through the whole sink chain only one at a time. In this case there
> will
> be only one event traveling the callbacks at a time. This approach
> though avoids the blocking of the execution of the application and
> guarantees the order might lead to the following problems:
> 1) The events might start to pile up in the queue due to one sink
> being
> faulty. This is bad.
> 2) If caller wants to call sync interface to log event, the queue must
> be emptied first if the sync call uses same loop. Steven was
> suggesting
> to use a different (internal) loop for the sync functions.
> This can cause even more problems with the order of the events.
> Imagine
> two parallel event loops trying to pump events into the same set of
> sinks... The events will be logged out of sequence for sure.

This is what you should do (except the suggestion to use different
loops).
Yes, a flaky sink will make things slow, that's ok, a completely sync
api would have the same issue.

Although, you may decide to let applications decide if they care about
order and make the ordered queue optional (ordered by default), so
admins/apps can decide whether they care or not.

Time stamping at the time of delivery would be bad as you can't
reconstruct what happened in the code and would have no way to correlate
what happened with other sources.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list