This is actually a release blocker
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.
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.
Ok. Thank you. Here is another way to do it.
Write to target and that will be cleaned up by mvn clean.
@Brock Were you suggesting that I add the path setting in here and then just call this method?
private void openLocalDiscoveryClient()
Latest patch looks good!
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.
Adding web link to RB
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?
$ git clean -df
Looks like the directory still gets left behind
Note that it was without the patch on this jira that the directory was left behind
Hi Jeff, do you have time to update this patch? Still seeing the issue.
Jeff I am applying a version of your patch and committing as RM. Attached here as FLUME-1741-3.patch
Pushed to trunk and flume-1.4 branches.
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