gianm commented on a change in pull request #11879:
URL: https://github.com/apache/druid/pull/11879#discussion_r743987838
##########
File path: core/src/main/java/org/apache/druid/java/util/common/FileUtils.java
##########
@@ -379,6 +379,27 @@ public static File createTempDir(@Nullable final String
prefix)
}
}
+ /**
+ * Create "directory" and all intermediate directories as needed. If the
directory is successfully created, or already
+ * exists, returns quietly. Otherwise, throws an IOException.
+ *
+ * Simpler to use than {@link File#mkdirs()}, and more reliable since it is
safe from races where two threads try
Review comment:
Ah, I see. Well: to avoid reporting an error when the directory already
exists, you have to do either `isDirectory() || mkdirs()` or `mkdirs() ||
isDirectory()`. The first one is prone to races and the second is race-proof.
So, since you have to pick one, we might as well do the second.
One place where this would matter is the LocalDataSegmentPusher, which needs
to create a directory for a datasource when pushing a new segment. But what
happens if two threads (or even two task JVMs on the same server) need to push
a segment for the same datasource at the same time? It needs a race-proof
approach for that to work properly. It's OK today, because it uses
`org.apache.commons.io.FileUtils.forceMkdir` which is race-proof.
But, it'd be good for it to be able to safely use our FileUtils. Actually,
if you don't mind I'd like to migrate it in this PR and add
`org.apache.commons.io.FileUtils.forceMkdir` to the forbidden-apis list. Two
reasons for that: (1) even though the commons-io version is race-proof, it's
not guaranteed by the javadoc, so it may not be safe to rely on it; (2), it's
annoying to use both FileUtils, because you can't import both in the same file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
