[metrics-bugs] #22141 [Metrics/metrics-lib]: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 3 14:25:02 UTC 2017
#22141: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
-------------------------------------+--------------------------
Reporter: karsten | Owner: metrics-team
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Metrics/metrics-lib | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
-------------------------------------+--------------------------
I'd want us to implement #20395 where we'd be able to handle much larger
descriptor files without copying all contents to memory before even
looking at them. But I realized that `DescriptorFile#getDescriptors()`
makes this rather pointless. If we need to keep a list with all parsed
descriptors in memory, each containing raw contents of some sort (see
#22140), then what's the point of avoiding to read complete files to
memory?
One way to fix this is to deprecate `DescriptorFile` and add all relevant
information to `Descriptor`. And then `DescriptorReader` would return an
`Iterator<Descriptor>`, internally backed by
`BlockingIteratorImpl<Descriptor>`, rather than an
`Iterator<DescriptorFile>`. Sounds easy!
Here's a catch though: `DescriptorFile#getException()` returns "the first
exception that was thrown when reading this file or parsing its content".
If we'd move this method to `Descriptor`, would we set an I/O exception to
the first descriptor in that file, to all of them, or maybe to none of
them? Turns out we don't have to worry too much about this. The only
code that actually uses `DescriptorFile#getException()` is Onionoo's
`DescriptorQueue`, and all it does is log the exception. We could just do
the same.
What else could go wrong?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22141>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the metrics-bugs
mailing list