[
https://issues.apache.org/jira/browse/SOLR-14256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061673#comment-17061673
]
ASF subversion and git services commented on SOLR-14256:
--------------------------------------------------------
Commit 4fd96bedc27adff61f3487539adbd67011181b90 in lucene-solr's branch
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4fd96be ]
SOLR-14256: replaced EMPTY with empty() to fix deadlock
> Remove HashDocSet
> -----------------
>
> Key: SOLR-14256
> URL: https://issues.apache.org/jira/browse/SOLR-14256
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This particular DocSet is only used in places where we need to convert
> SortedIntDocSet in particular to a DocSet that is fast for random access.
> Once such a conversion happens, it's only used to test some docs for presence
> and it could be another interface. DocSet has kind of a large-ish API
> surface area to implement. Since we only need to test docs, we could use
> Bits interface (having only 2 methods) backed by an off-the-shelf primitive
> long hash set on our classpath. Perhaps a new method on DocSet: getBits() or
> DocSetUtil.getBits(DocSet).
> In addition to removing complexity unto itself, this improvement is required
> by SOLR-14185 because it wants to be able to produce a DocIdSetIterator slice
> directly from the DocSet but HashDocSet can't do that without sorting first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
