[
https://issues.apache.org/jira/browse/LUCENE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937460#comment-13937460
]
Robert Muir commented on LUCENE-5532:
-------------------------------------
I am also unhappy about this:
{code}
// we already minimized the automaton in the ctor, so
// this hash code will be the same for automata that
// are the same:
int automatonHashCode = automaton.getNumberOfStates() * 3 +
automaton.getNumberOfTransitions() * 2;
{code}
This comment is out of date! So the whole algorithm is broken in some cases I
think.
I would really prefer if we don't mess with mutable stuff in equals/hashcode.
I think it would be better if this stuff was impl'ed in CompiledAutomaton? I'll
give it a stab.
> AutomatonQuery.hashCode is not thread safe
> ------------------------------------------
>
> Key: LUCENE-5532
> URL: https://issues.apache.org/jira/browse/LUCENE-5532
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> This hashCode is implemented based on #states and #transitions.
> These methods use getNumberedStates() though, which may oversize itself
> during construction and then "size down" when its done. But numberedStates is
> prematurely set (before its "ready"), which can cause a hashCode call from
> another thread to see a corrupt state... causing things like NPEs from null
> states and other strangeness. I don't think we should set this variable until
> its "finished".
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
