[
https://issues.apache.org/jira/browse/SOLR-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14015231#comment-14015231
]
Dawid Weiss commented on SOLR-6119:
-----------------------------------
There seem to be other problems with this test too, do you know how to fix
these, Varun? Here's my comment on the dev list for this failure:
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10446/consoleText
Ok, I don't know what's going on but I know this sequence at the start
of the test:
masterJetty.stop();
masterClient.shutdown();
doesn't do anything to stop existing snappuller; if you breakpoint
after the above you still get periodic calls to:
> org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:311)
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:337)
> org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:226)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:724)
> TestReplicationHandler attempts to remove open folders
> ------------------------------------------------------
>
> Key: SOLR-6119
> URL: https://issues.apache.org/jira/browse/SOLR-6119
> Project: Solr
> Issue Type: Bug
> Reporter: Dawid Weiss
> Priority: Minor
> Attachments: SOLR-6119.patch, SOLR-6119.patch, SOLR-6119.patch,
> SOLR-6119.patch
>
>
> TestReplicationHandler has a weird logic around the 'snapDir' variable. It
> attempts to remove snapshot folders, even though they're not closed yet. My
> recent patch uncovered the bug but I don't know how to fix it cleanly -- the
> test itself seems to be very fragile (for example I don't understand the
> 'namedBackup' variable which is always set to true, yet there are
> conditionals around it).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
