Simo Sorce wrote:
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
> 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
> 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
> to use a different (internal) loop for the sync functions.
> This can cause even more problems with the order of the events.
> 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
Yes, a flaky sink will make things slow, that's ok, a completely sync
api would have the same issue.
If I understand you correctly you agree that having an internal queue is
the right approach.
Do you agree with the recommendation to use different dispatchers if
application wants to log sync and async events at the same time?
Or do you think one dispatcher should be capable of working with
external and internal loop at the same time and give the caller a choice
which loop to use within the dispatcher? But then why not just create
the second dispatcher?
Although, you may decide to let applications decide if they care
order and make the ordered queue optional (ordered by default), so
admins/apps can decide whether they care or not.
I do not think we can allow this. Think about the central collection
server that deals with all these logs.
One of the goals of ELAPI is to make its work easier. Consciously
allowing unordered logging would force the server to understand it. I
do not think we or anyone else wants to implement such logic on the
server. Time ordered logs are one of the basic assumptions of many of
If we do not allow it then we can treat it as a bug in the application
or configuration and ask the vendor or admin to fix it.
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.
yes. I share the same concern.
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?