[
https://issues.apache.org/jira/browse/LUCENE-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736307#action_12736307
]
Mark Miller commented on LUCENE-1764:
-------------------------------------
Bug was a bit strong I guess - resource hog trap? - you can sidestep this if
you implement hashcode/equals on your SortComparator. We need a warning to do
that I think.
For the unit test that fails, I've changed the equals/hashcode for the
SortComparator to use:
//@Override
public int hashCode() {
return getClass().getName().hashCode();
}
//@Override
public boolean equals(Object other) {
return this.hashCode() == other.hashCode();
}
We have always had the issue, because the comparator has been part of the key,
and when you pass a SortField over the wire, you get a new impl of the
comparator factory field thats in it.
> Remote Searching w/sort using SortComparator has explosive FieldCache usage
> ---------------------------------------------------------------------------
>
> Key: LUCENE-1764
> URL: https://issues.apache.org/jira/browse/LUCENE-1764
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Hoss Man
> Fix For: 2.9
>
>
> As discovered in LUCENE-1749, when using identical instances of a
> SortComparator you get multiple entries in the FieldCache.
> demonstrating this bug currently requires the patches in LUCENE-1749.
> See markmiller's comment here...
> https://issues.apache.org/jira/browse/LUCENE-1749?focusedCommentId=12735190#action_12735190
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
