Improve performance for operations that modify framework state #54
Conversation
File.createTempFile uses SecureRandom under the covers to generate unique file names. This may be important for when storing files in the global temporary file space to avoid something guessing the file and writing to it. The usage in the framework for createTempFile is always used for staging file content before it gets (reliably) moved to its final destination. This always happens as an implementation detail of storing some state in the internal file storage of the framework. Risk is low that some malicious code would be able to predict the temporary file and somehow interfere with the behavior of the framework. Once some malicious code has had access to the internal storage of the framework they will be able to write to other files that have very predictable names to cause issues.
...lipse.osgi/supplement/src/org/eclipse/osgi/framework/internal/reliablefile/ReliableFile.java
Outdated
Show resolved
Hide resolved
If we really have this many temporary files there is something wrong that needs to be addressed. Fail with IOException if we detect a 100000 attempts to find a non-existing file
tjwatson
force-pushed
the
creatTempFileNoSecureRandom
branch
from
03d3eae to
56fcf01
Compare
|
@tjwatson just wondering: Does it really matters how the file is named? Maybe instead of using a prefix, one could simply use an UUID.randomUUID() as a start, then, if the file exits simply add a (local) incrementing number, this should not require a global counter and in almost all cases give a unique filename at the first try. |
|
|
One bit of detail I left out so far. The motivation for this change is for systems where there is contention for the system resource that produces random numbers from the OS (e.g. |
|
Never have had though that this is an issue at all, is the OSGi framework creating that many files? |
The answer is, it depends. In one scenario I was investigating recently it was a testcase running many different instances of the framework and each one installing lots of bundles. The staging happens for each bundle stored in the framework. This ultimately lead to a bottleneck and some timeouts in our tests. |
Many places in the internal management of framework state use File.createTempFile to stage updates before moving them to their final location on disk. The issue is File.createTempFile uses SecureRandom to generate unique file names. This is a bit overkill for our usages and can cause slowdown on some environments when used extensively.
This change implements a simple version of createTempFile that can be used for only internal purposes for the framework.