-
Type: Bug
-
Status: Closed (View Workflow)
-
Priority: Critical
-
Resolution: Done
-
Affects Version/s: 1.3.0
-
Fix Version/s: 1.3.0
-
Component/s: None
-
Labels:None
-
Epic Link:
-
Sprint:Drake Sprint 3 (8/17-8/28)
Evidence shows that the accumulator is not working as advertised.
The TopologyViewMessageHandler has an InternalEventAccumulator extends AbstractAccumulator<Event>. and parameterized with:
max-events = 1000, max-batch-ms = 5000, max-idle-ms = 1000
The following lines were added to processItems()...
// Start-of-Debugging
long now = System.currentTimeMillis();
String me = this.toString();
String miniMe = me.replaceAll("^.*@", "me@");
log.debug("Time: {}; this: {}, processing items ({} events)",
now, miniMe, items.size());
// End-of-Debugging
In the log, the following entries were observed (after issuing a "pingall" command on a tower topology, which caused a lot of events).
Time: 1439323590176; this: me@20a4f2f8, processing items (1178 events) |
Time: 1439323590176; this: me@20a4f2f8, processing items (28 events) |
Time: 1439323590176; this: me@20a4f2f8, processing items (12 events) |
Time: 1439323590176; this: me@20a4f2f8, processing items (11 events) |
Time: 1439323590176; this: me@20a4f2f8, processing items (12 events) |
Time: 1439323590176; this: me@20a4f2f8, processing items (12 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (53 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (13 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (10 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (8 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (7 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (7 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (6 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (12 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (9 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (9 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (17 events) |
Time: 1439323590177; this: me@20a4f2f8, processing items (10 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (10 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (8 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (8 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (3 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (5 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (6 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (7 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (7 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (7 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (6 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (24 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (1 events) |
Time: 1439323590178; this: me@20a4f2f8, processing items (9 events) |
Time: 1439323590179; this: me@20a4f2f8, processing items (10 events) |
Time: 1439323590179; this: me@20a4f2f8, processing items (15 events) |
Time: 1439323590179; this: me@20a4f2f8, processing items (1 events) |
Note the multiple small-number-of-event firings of the processItems() method, all within the space of a couple of milliseconds. After the initial 1178 events, the additional events should have accumulated into one (or two at most?) invocations of the processItems() method, not the 33 additional invocations seen here.
Note:
At a minimum, the following code in AbstractAccumulator.ProcessorTask.run() should be added:
List<T> items = finalizeCurrentBatch();
if (!items.isEmpty())
so that processItems is NOT called when there is nothing to process (which has been observed). Note that the log entries shown above were taken with this suppression of empty lists in place (but the change was not checked in).