|
Ran
|
Jobs
4
|
Files
71
|
Run time
3min
|
Badge
README BADGES
|
push
travis-ci
T112686: Use a timer to ensure forward progress in batched dispatches * Rejiggered the dispatching a bit to ensure that we are guaranteed to make forward progress independent of the idiosyncrasies of events get scheduled (because of implementation details of Parsoid's async pipeline or node's event loop). * Normally, the dispatch -> batch-response -> dispatch -> ... pipeline keeps batch requests flowing smoothly. The only problem is how to kickstart this pipeline at the start and whenever the pipeline stops in the middle when there are no outstanding batch requests. This is handled as follows: 1. Whenever a request comes in, schedule a 0ms timer to check if we are stuck and need to make forward progress. 2. If a new request comes in before the timer trips, reset the timer -- this minimizes premature dispatch of unfilled batches. 3. Whenever a batch reaches the max batch size, always dispatch it. 4. If the timer trips and we don't have anything outstanding, dispatch whatever we have. * Because of the new requirement to always dispatch whenever we receive a response, I removed the idleTimer. We can dispatch immediately without scheduling it in an event loop. * I removed the async TTM from the batching dispatch equation. * Verified that: - this fixes the parse of the request in the bug report. - this reduces the # of dispatched batches. With enwiki:Barack_Obama page, this reduced # of dispatched batches from 31 -> 22 without impacting parse latencies. * Unrelated changes: - a bunch of fragility tweaks and cleanup. Co-authored by: Subramanya Sastry, Tim Starling, C.Scott Ananian Change-Id: I3c2b7d0dc
11915 of 13997 relevant lines covered (85.13%)
77537.0 hits per line
| ID | Job ID | Ran | Files | Coverage | |
|---|---|---|---|---|---|
| 1 | 696.1 | 0 |
85.13 |
Travis Job 696.1 | |
| 2 | 696.2 | 0 |
85.13 |
Travis Job 696.2 | |
| 3 | 696.3 | 0 |
85.12 |
Travis Job 696.3 | |
| 4 | 696.4 | 0 |
85.12 |
Travis Job 696.4 |