lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Resolved: (SOLR-22) BitDocSet can get corrupt size info?
Date Wed, 07 Jun 2006 20:30:30 GMT
     [ ]
Yonik Seeley resolved SOLR-22:

    Resolution: Fixed
     Assign To: Yonik Seeley

fixed.  size is invalidated if addUnique is used.
The efficient workaround to build a BitSet and construct a BitDocSet is to keep track of the
number of bits set yourself and use the constructor that takes that.

Makes me wonder if addUnique should just be removed...
add/addUnique aren't supported in all subclasses of DocSet anyway.

> BitDocSet can get corrupt size info?
> ------------------------------------
>          Key: SOLR-22
>          URL:
>      Project: Solr
>         Type: Bug

>     Reporter: Hoss Man
>     Assignee: Yonik Seeley

> I don't have a test case demonstrating this yet, but i wnated to file it before i forget.
> Glancing at the code for BitDocSet this morning i think i see a way for the size information
(which is cached) to be corrupted.
> If a client tries to be helpful by using addUnique when it knows it can, but the size
cache is already invalid, then the size will be recorded incorrectly as 0 (which will now
be considered a valid (but incorect) size, which may be further trusted for additional addUnique
> ie...
>     DocSet a = ...                   # get a BitDocSet from somewhere
>     a.add(42);                        # this internal sets size=-1 since we don't know
if 42 was alreayd set so we don't trust the cache
>     if (! a.exists(666) ) {
>        ...                                   # client does it's thing
>        a.addUnique(666);        # client tries to be helpfull, but at this point size
is incrimented to 0, making it a legal value
>     }
>     int s = a.size();                # bogus 0 is returned.
> the most straight forward fix may be to decouple a boolean indicating wether the cached
value is valid from the actual cached value.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message