TracerouteEngineImpl: limit number of traces materialized from TraceDag.#8939
TracerouteEngineImpl: limit number of traces materialized from TraceDag.#8939
Conversation
TraceDags have been observed to contain huge numbers of traces, too many to materialize into a list. Limiting to 10k for now. Rewrote TraceDagImpl to use iterators internally, as limit() wasn't working on the previous implementation based on recursive streams flattened with flatMap. Something about the stream implementation materializes many more traces than the limit, which wastes compute time and risks OOM. Rewriting using the same style of code but based on iterators solved the problem.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #8939 +/- ##
==========================================
- Coverage 72.53% 72.52% -0.01%
==========================================
Files 3321 3323 +2
Lines 169579 169605 +26
Branches 19912 19914 +2
==========================================
+ Hits 123003 123009 +6
- Misses 37415 37432 +17
- Partials 9161 9164 +3
|
dhalperi
left a comment
There was a problem hiding this comment.
Reviewed 4 of 4 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @anothermattbrown)
projects/batfish/src/main/java/org/batfish/dataplane/TracerouteEngineImpl.java line 69 at r1 (raw file):
.getValue() .getTraces() .limit(10000)
would probably 1/ extract to a constant in the interface 2/ add a limited variant in the interface where this const is the default 3/ migrate interface default impl to be the limited version of the constant.
Code quote:
10000
dhalperi
left a comment
There was a problem hiding this comment.
Reviewed 3 of 3 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @anothermattbrown)
TraceDags have been observed to contain huge numbers of traces, too many to materialize into a list. Limiting to 10k for now. Rewrote TraceDagImpl to use iterators internally, as limit() wasn't working on the previous implementation based on recursive streams flattened with flatMap. Something about the stream implementation materializes many more traces than the limit, which wastes compute time and risks OOM. Rewriting using the same style of code but based on iterators solved the problem.