[
https://issues.apache.org/jira/browse/LUCENE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865610#comment-16865610
]
Atri Sharma commented on LUCENE-8862:
-------------------------------------
{quote}Memory accounting has a cost API-wise
{quote}
Agreed, I was thinking of adding it as a default method which is essentially a
no-op.
{quote}The only collectors I have in mind that might allocate lots of memory
are the ones that are used to collect matches in a bitset
{quote}
Yeah, that is true. However, my bigger objective is to allow a generic
interface for consuming and using this data (wherever it is exposed). For eg, I
was thinking of adding a Collector which can wrap other Collectors and provide
a way to fence memory usage.
Other way to think about this is if we should add a similar mechanism like
QueryVisitor to Collectors, and then pursue an effort to add memory collection
heuristics to both QueryVisitor and the Collector visitor. Having the Collector
visitor interface will provide ways to have deeper functionality than just the
memory accounting. WDYT?
> Collector Level Dynamic Memory Accounting
> -----------------------------------------
>
> Key: LUCENE-8862
> URL: https://issues.apache.org/jira/browse/LUCENE-8862
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Atri Sharma
> Priority: Major
>
> Inspired from LUCENE-8855, I am thinking of adding a new interface which
> tracks dynamic memory used by Collectors. This shall allow users to get an
> accountability as to the memory usage of their Collectors and better plan
> their resource capacity. This shall also allow us to add Collector level
> limits for memory usage, thus allowing users a finer control over their
> resources.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
