[
https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13543186#comment-13543186
]
Yonik Seeley edited comment on SOLR-3180 at 1/4/13 12:15 AM:
-------------------------------------------------------------
Here's another interesting tidbit:
{code}
2> "recoveryExecutor-140-thread-1" Id=320 TIMED_WAITING
2> at java.lang.Thread.sleep(Native Method)
2> at
org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:925)
2> at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:330)
2> at
org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1268)
2> at
org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1159)
2> at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
2> at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
2> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
2> ...
2>
2> Number of locked synchronizers = 1
2> - java.util.concurrent.locks.ReentrantLock$NonfairSync@1f2eb71e
{code}
Seems like we shouldn't check ZK if the update is from log replay or from
peersync (basically if distrib=false?)
edit: I just committed SOLR-4257, which should handle these cases.
was (Author: [email protected]):
Here's another interesting tidbit:
{code}
2> "recoveryExecutor-140-thread-1" Id=320 TIMED_WAITING
2> at java.lang.Thread.sleep(Native Method)
2> at
org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:925)
2> at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:330)
2> at
org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1268)
2> at
org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1159)
2> at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
2> at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
2> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
2> ...
2>
2> Number of locked synchronizers = 1
2> - java.util.concurrent.locks.ReentrantLock$NonfairSync@1f2eb71e
{code}
Seems like we shouldn't check ZK if the update is from log replay or from
peersync (basically if distrib=false?)
> ChaosMonkey test failures
> -------------------------
>
> Key: SOLR-3180
> URL: https://issues.apache.org/jira/browse/SOLR-3180
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Yonik Seeley
> Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt,
> fail.130101_034142.txt, fail.130102_020942.txt, fail.130103_105104.txt,
> fail.inconsistent.txt, test_report_1.txt
>
>
> Handle intermittent failures in the ChaosMonkey tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
