[ 
https://issues.apache.org/jira/browse/SOLR-9030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258560#comment-15258560
 ] 

Scott Blum commented on SOLR-9030:
----------------------------------

The final keyword conveys special thread-safety semantics in the JMM.
https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5

I don't know that this is actually the bug, but because DocCollection 
initializes znodeVersion to -1 before subsequently setting it to the 'correct' 
value, it's not out of the question that this could expose a data race that 
marking the field 'final' would have prevented.  We should make that change 
anyway.  Here's another description with a code example:

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#finalRight

I don't think "effectively final" has any special meaning for instance fields; 
the compiler can infer that local variables are effectively final through 
static analysis, but the compiler can't know whether or not you might modify a 
non-final instance field via reflection.

> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-9030
>                 URL: https://issues.apache.org/jira/browse/SOLR-9030
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Shalin Shekhar Mangar
>             Fix For: master, 6.1
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>    [junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>    [junit4]    > Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_0000000000,
>  state=RUNNABLE, group=Overseer state updater.]
>    [junit4]    >      at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>    [junit4]    > Caused by: java.lang.AssertionError
>    [junit4]    >      at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>    [junit4]    >      at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>    [junit4]    >      at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>    [junit4]    >      at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to