filterCache ramBytesUsed monitoring statistics go negative

[Dawn <li...@live.com>]

Hi:

	filterCache ramBytesUsed monitoring statistics go negative.

	Is there a special meaning, or is there a statistical problem
 
	When present the list, can sort it by key. Solr7 is like this, easy to view.


For example:

CACHE.searcher.filterCache.hits:
    63265

CACHE.searcher.filterCache.cumulative_evictions:
    1981

CACHE.searcher.filterCache.size:
    6765

CACHE.searcher.filterCache.maxRamMB:
    10240

CACHE.searcher.filterCache.hitratio:
    0.8329712577846243

CACHE.searcher.filterCache.warmupTime:
    49227

CACHE.searcher.filterCache.evictions:
    1981

CACHE.searcher.filterCache.cumulative_hitratio:
    0.737519464195261

CACHE.searcher.filterCache.lookups:
    75951

CACHE.searcher.filterCache.cumulative_hits:
    78624

CACHE.searcher.filterCache.cumulative_inserts:
    15927

CACHE.searcher.filterCache.ramBytesUsed:
    -1418740612

CACHE.searcher.filterCache.inserts:
    10510

CACHE.searcher.filterCache.cumulative_lookups:
    106606

Re: filterCache ramBytesUsed monitoring statistics go negative

[Shawn Heisey <ap...@elyograg.org>]

On 11/2/2020 4:27 AM, Dawn wrote:
> 	filterCache ramBytesUsed monitoring statistics go negative.
> 	Is there a special meaning, or is there a statistical problem
> 	When present the list, can sort it by key. Solr7 is like this, easy to view.

When problems like this surface, it's usually because the code uses an 
"int" variable somewhere instead of a "long".  All numeric variables in 
Java are signed, and an "int" can only go up to a little over 2 billion 
before the numbers start going negative.

The master code branch looks like it's fine.  What is the exact version 
of Solr you're using?  With that information, I can check the relevant code.

Maybe simply upgrading to a much newer version would take care of this 
for you.

Thanks,
Shawn