[
https://issues.apache.org/jira/browse/LUCENE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937619#comment-13937619
]
Uwe Schindler commented on LUCENE-5532:
---------------------------------------
bq. 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
All fine, just wanted to be sure. And we dont have Thread#<init>() on the
forbidden list :-)
bq. 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
Yes it will loose. I dont like RuntimeExceptions wrapping others. You can
ideally do Rethrow.rethrow(ex). In tests this is I think the preferred way. You
will get the original Exception in the thread stack dump, unwrapped. This is
why we have Rethrow class in test framework.
> 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]
