Hi,
The problem is also the security manager and it's policy file. This is why we
have the temp dir in current folder. As there is no easy way to have an
absolute path in the policy file, we have it like this. Another way would be to
pass a sys prop for the temp directory and add a policy file
Check this out: (FYI this is my test; doesn't exist upstream yet):
> ant test -Dtestcase=HeatmapSpatialFieldTest
BUILD SUCCESSFUL, 1 minute 40 seconds
> ant test-core -Dtestcase=HeatmapSpatialFieldTest
BUILD FAILED, 25 seconds
So it turns out the "-init-totals" task sets up the temp dir
It's exactly that, actually. We place java.io.tmpdir under ./, so this
directory always remains after the tests are done. I filed this issue:
https://github.com/randomizedtesting/randomizedtesting/issues/247
But I honestly don't know what the "right" way to fix it is. The
runner assumes cwd
No problem at all. I wonder if we (in Lucene) don't point the temp
folder under cwd -- we probably do... If so then this is something I
didn't give much thought to... special case which should probably be
allowed. Check common-build and confirm if this is the case.
Dawid
On Mon, Jan 23, 2017 at
Thanks very much Dawid. So indeed, the directory in question isn't quite
empty; it contains a "temp" directory (that is empty). Off to the next
thing to debug
Thanks again.
~ David
On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss wrote:
> I've committed LUCENE-7653
I've committed LUCENE-7653 which should help you diagnose the problem,
David. First, it'll clean the cwd of a forked process before the tests
start (something that wasn't done before). Second, it'll report what
files remained uncleaned after a run.
Hope it'll help.
Dawid
On Fri, Jan 20, 2017 at
Hi David!
> I can't find the string "Could not remove temporary path" in our codebase;
> maybe it's in randomized-testing? (CC Dawid) I'm not sure how to debug
> this... maybe Solr wasn't closed properly? Although this doesn't happen
Yes, this message has a source in ANT's unit test runner
I wrote a test in Solr extending SolrTestCaseJ4 that sets up Solr a bit
differently than some tests. Essentially instead of writing yet another
test schema.xml file, I decided to use some stock configs that are already
in a managed-schema mode that allow me to manipulate the schema via test
code