[metrics-bugs] #22514 [Metrics/metrics-lib]: Replace DescriptorReader's setMaxDescriptorFilesInQueue() with setMaxMemory()

[Tor Bug Tracker & Wiki]

#22514: Replace DescriptorReader's setMaxDescriptorFilesInQueue() with
setMaxMemory()
---------------------------------+-----------------------------------
 Reporter:  karsten              |          Owner:  metrics-team
     Type:  enhancement          |         Status:  needs_review
 Priority:  Medium               |      Milestone:  metrics-lib 1.9.0
Component:  Metrics/metrics-lib  |        Version:
 Severity:  Normal               |     Resolution:
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
 Reviewer:                       |        Sponsor:
---------------------------------+-----------------------------------

Comment (by karsten):

 Replying to [comment:3 iwakeh]:
 > I really want direct unit tests for the new functionality of
 `BlockingIteratorImpl`.

 Good idea.

 > There are some (older) `System.err.printf` statements that should be
 turned into log statements.

 Makes sense to do that.

 > With this change `BlockingIteratorImpl` is not generic anymore as it now
 is tightly coupled with Descriptor and DescriptorFile.  So, it seems
 better to either make it a BlockingDescriptorIterator or derive
 BlockingDescriptorIterator from the generic old implementation (if
 possible) or find another way of keeping it decoupled from
 Descriptor/Desc.File.

 True.  I guess we could go for the non-generic
 `BlockingDescriptorIterator`, because we'll only put `Descriptor`s in it.
 That was different with `DescriptorFile` and `DescriptorRequest` a while
 ago.  But we're going to stop using `BlockingIteratorImpl<DescriptorFile>`
 in 2.0.0 anyway, so we could just start a new class now and delete the
 existing class next week.

 But before I make changes here: what's your preference for having a
 setting a maximum number of ''descriptors'' vs. ''raw descriptor bytes''?
 The former is easier to implement (possibly even with existing Java
 Collections classes) whereas the latter might be more intuitive to use
 (people might have a better idea specifying a bytes limit rather than a
 more abstract descriptor limit).  What do you think?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22514#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online