You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2013/10/10 13:09:43 UTC

[jira] [Commented] (SOLR-5330) PerSegmentSingleValuedFaceting overwrites facet values

    [ https://issues.apache.org/jira/browse/SOLR-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791394#comment-13791394 ] 

Erick Erickson commented on SOLR-5330:
--------------------------------------

Michael:

Thanks for the detailed explanation! Could I trouble you to go ahead and attach a patch? Don't worry about "polish", having your code change as a place to at least start (if not use entire) makes things easier for whoever picks this up...

> PerSegmentSingleValuedFaceting overwrites facet values
> ------------------------------------------------------
>
>                 Key: SOLR-5330
>                 URL: https://issues.apache.org/jira/browse/SOLR-5330
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.2.1
>            Reporter: Michael Froh
>
> I recently tried enabling facet.method=fcs for one of my indexes and found a significant performance improvement (with a large index, many facet values, and near-realtime updates). Unfortunately, the results were also wrong. Specifically, some facet values were being partially overwritten by other facet values. (That is, if I expected facet values like "abcdef" and "123", I would get a value like "123def".)
> Debugging through the code, it looks like the problem was in PerSegmentSingleValuedFaceting, specifically in the getFacetCounts method, when BytesRef val is shallow-copied from the temporary per-segment BytesRef. The byte array assigned to val is shared with the byte array for seg.tempBR, and is overwritten a few lines down by the call to seg.tenum.next().
> I managed to fix it locally by replacing the shallow copy with a deep copy.
> While I encountered this problem on Solr 4.2.1, I see that the code is identical in 4.5. Unless the behavior of TermsEnum.next() has changed, I believe this bug still exists.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org