DisasterRouter: Cache message ordering
Merge request reports
Activity
added Needs wiki documentation label
68 * newly created or received messages are not directly sent to other hosts as they are not in the cache yet, while 69 * messages deleted from cache might still be sent. We can tolerate this as long as {@link #messageOrderingInterval} 70 * is not chosen too high. 71 */ 61 72 private List<Message> cachedMessages = new ArrayList<>(); 62 /** When the messages (not for final delivery) were last ordered, initially Double.NEGATIVE_INFINITY */ 73 /** 74 * When the messages (for final delivery) were last recomputed and ordered, initially 75 * {@link Double#NEGATIVE_INFINITY}. 76 */ 63 77 private double lastMessageOrderingForConnected = Double.NEGATIVE_INFINITY; 64 /** Ordered messages which are final deliveries */ 78 /** 79 * A cache for direct messages to all neighbors, sorted in the order in which they should be sent. 80 * The cache is recomputed every {@link #messageOrderingInterval} seconds. 81 * As soon as a connection breaks, the respective messages are removed from this cache. The indentation seems to be messed up due to mixing of spaces and tabs. The rest of the MR is fine, no complaints. I would not have thought caching the ordering would decrease the runtime that much. How great is this messageOrderingInterval, compared to the time window size of the DP?
MessageOrderingInterval is 2 (in comparison with a usual step size of 0.1), same as we do for Epidemic (!79 (merged), !83 (merged)). Window size is 30.
Maybe we could invalidate the caches as well when one of the rating mechanisms is updated at the end of its time window (e.g. here we would still use the old order computed with the old rating for 20 steps in the worst case). But maybe it is neglectable as the ordering interval is quite small compared to the time window.
SonarQube analysis reported 1 issue
-
⚠ 1 major
-
mentioned in commit 5927ad62
removed Needs wiki documentation label