This is actually a release blocker
Integrated in flume-trunk #443 (See https://builds.apache.org/job/flume-trunk/443/)
FLUME-1741. ElasticSearch tests leave directory data/elasticsearch/nodes/ lying around. (Revision 1e2261ce04c9725256b5e99812e04cc1ceb3d636)
Result = UNSTABLE
mpercy : http://git-wip-us.apache.org/repos/asf/flume/repo?p=flume.git&a=commit&h=1e2261ce04c9725256b5e99812e04cc1ceb3d636
Pushed to trunk and flume-1.4 branches.
Jeff I am applying a version of your patch and committing as RM. Attached here as FLUME-1741-3.patch
Hi Jeff, do you have time to update this patch? Still seeing the issue.
Note that it was without the patch on this jira that the directory was left behind
$ git clean -df
Looks like the directory still gets left behind
Mike and Hari I don't think this one is an issue any longer.
On latest trunk the data directory is not left behind.
Can you please let me know if you observe different behavior?
Adding web link to RB
Marking as "Patch Available" so devs can query on open issues needing review when they are not on review board. This should probably also be posted to RB.
Latest patch looks good!
@Brock Were you suggesting that I add the path setting in here and then just call this method?
private void openLocalDiscoveryClient()
Ok. Thank you. Here is another way to do it.
Write to target and that will be cleaned up by mvn clean.
I think that we should be setting path.data for in openLocalDiscoveryClient in ElasticSearchSink.
node = NodeBuilder.nodeBuilder().client(true).local(true).node();
could have a settings added to it.
Realize this sets the DEFAULT_TEMP_DIR as a constant to data. Wasn't able to find where this object is held in es. Please let me know if there is a more appropriate way to handle this.