[
https://issues.apache.org/jira/browse/LUCENE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937611#comment-13937611
]
Robert Muir commented on LUCENE-5532:
-------------------------------------
Uwe, it just inherits. Its similar to many tests in the .index package that
work this way. If we want to do something else, we should ban some methods. But
I can name the threads if you want :)
As far as Assert.fail, this would lose the stacktrace of the original
exception? In the case of this test failing due to a thread safety issue, I
think thats useful for debugging
> 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
> Attachments: LUCENE-5532.patch, LUCENE-5532.patch
>
>
> 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]
