You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2016/04/27 00:26:13 UTC
[jira] [Comment Edited] (SOLR-9030) The 'downnode' command can trip
asserts in ZkStateWriter or cause BadVersionException in Overseer
[ https://issues.apache.org/jira/browse/SOLR-9030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259068#comment-15259068 ]
Mark Miller edited comment on SOLR-9030 at 4/26/16 10:25 PM:
-------------------------------------------------------------
Like I said though, those thread-safety semantics apply when you share an object across threads without safe publication. We do safe publication in this case.
When DocCollection is shared across threads, it's container object (clusterstate) is published with a volatile (or an atomicreference now?), and any member fields of that volatile object will be fully initialized and sharable across threads as long as they are effectively immutable.
If we wanted to just share a DocCollection across threads and there was no memory barrier, then they would have to be final and take advantage of the special thread safety semantics in the JVM.
was (Author: markrmiller@gmail.com):
Like I said though, those thread-safety semantics apply when you share an object across threads without safe publication. We do safe publication in this case.
When DocCollection is shared across threads, it is published with a volatile (or an atomicreference now?), and any member fields of that volatile object will be fully initialized and sharable across threads as long as they are effectively immutable.
If we wanted to just share a DocCollection across threads and there was no memory barrier, then they would have to be final and take advantage of the special thread safety semantics in the JVM.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org