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