Community
Participate
Working Groups
As a result of some event, multiple components can issue similar or overlapping data requests quasi simultaneously. Today, all requests are handled separately. It would more efficient for the experiment to coalesce the requests and then duplicate and dispatch the results as needed.
For the initial release (i.e. LTTng-oriented), this boils down to the following design requirements: [1] Shield a TmfProvider from multiple, simultaneous requests: it should service the requests in sequence, one at a time. [2] Make sure that all the "equivalent" requests had a chance to be received before processing them. [3] Coalesce the "equivalent" incoming requests into a single request, process it, and distribute the results among the initial requesters. [4] Request cancellation Item [1] is addressed by adding a RequestQueue and an Executor to the abstract base class. New requests will simply be queued and processed only when the previous ones have completed. Item [2] is addressed by the signal mechanism. It is assumed that multiple equivalent requests will be issued as a result of processing a signal (i.e. selection of a new experiment, navigation in the time window, etc...). When a signal is broadcast, the TmfSignalManager goes through the list of interested parties and distributes the signal. By bracketing the distributed signals with synch signals, it will be possible to correctly identify the requests that were generated as a result of distributing a given signal. Item [3] is addressed by saving the incoming requests into standalone, "equivalence" (request-wise) queues and building a new "equivalent" request for each queue. Upon receiving the end synch signal (item [2]), the "equivalent" requests can be queued and processed. The result can then be distributed among the entries ion the "equivalence" queues. Item [4] Not thought out yet but it boils down to finding and removing the canceled request from the right queue. Famous last words.
Created attachment 161325 [details] First draft - Added a request queue and an executor to the TmfDataProvider base class. The incoming requests are now executed in sequence. - Added synch signals to TmfSiognalManager and made TmfDataProvider a listener of these.
Comment on attachment 161325 [details] First draft Patch applied
Created attachment 161821 [details] Second Part Implementation of the "simple" request coalescing i.e. we only coalesce the requests that have identical parameters (enough for LTTng purposes and other synchronous apps). Cancel on individual requests is also implemented.
Comment on attachment 161821 [details] Second Part Patch commited
This implementation is limited to practically identical requests but it is sufficient for LTTng. A more comprehensive solution will be required for true coalescing (overlaps, subsets, etc..). However such a solution might prove very hard because we are processing data/events in chunks: once servicing a request has started, it is not obvious that a subsequent request can piggyback if results for the first request have started coming in prior to receiving the second request. Anyway, it will addressed by another bug.
Released in a previous delivery.
