Why does the first call to java.io.File.createTempFile (String, String, File) take 5 seconds on Citrix?
While debugging a slow start RCP Eclipse application on Citrix server, I came to find out that java.io.createTempFile (String, String, File) takes 5 seconds. It only does this on first run and only for certain user accounts. In particular, I notice this is anonymous Citrix accounts. I haven't tried many other types of accounts, but this behavior doesn't show up with an administrator account.
Also, it doesn't matter if the user has write access to the given directory or not. If the user does not have access, the call will last 5 seconds. If they have access, the call will take 5 seconds.
This is on a Windows 2003 server. I've tried Sun 1.6.0_16 and 1.6.0_19 JREs and see the same behavior.
I googled a bit expecting it to be some known issue, but found nothing. It seems like someone else should have encountered this before.
The Eclipse framework uses File.createTempFile () to check various directories to make sure they can be written during initialization, and this problem adds 5 seconds to our application's startup time.
I'm guessing someone has come across this before and might have some idea. Here is some sample code I followed to see that this particular call is consuming time. I also tried this with a second call to createTempFile and noticed that subsequent calls return almost instantly.
public static void main (final String [] args) throws IOException {
final File directory = new File (args [0]);
final long startTime = System.currentTimeMillis ();
File file = null;
try {
file = File.createTempFile ("prefix", "suffix", directory);
System.out.println (file.getAbsolutePath ());
} finally {
System.out.println (System.currentTimeMillis () - startTime);
if (file! = null) {
file.delete ();
}
}
}
The sample output from this program is as follows:
C: \> java.exe -jar filetest.jar C: / Temp C: \ Temp \ prefix8098550723198856667suffix 5093
source to share
It might be the initialization of a secure random number generator that is causing the problem. In particular, if a safe random seed cannot be obtained from the operating system, then the fallback engine tries to obtain entropy. IIRC, one of the things it does is to list the temporary files, so if you have a large number of those that won't help you get started.
source to share
It looks like the slowness is due to seeding SecureRandom and only when the user is in the Guests group.
Sample initialization SecureRandom uses the Windows Crypto API, which fails when the user is a guest, as described here [1]. By setting the system property "java.security.debug" to "all", I see the following when the program is launched as a guest:
ProviderConfig: Loaded provider SUN version 1.6 provider: Failed to use operating system seed generator: java.io.IOException: Required native CryptoAPI features not available on this machine provider: Using default threaded seed generator
When run as a non-guest user, the output is as follows:
ProviderConfig: Loaded provider SUN version 1.6 provider: Using operating system seed generator
It looks like the default seed generator is pretty slow. Here [2] is a very old magazine filed with Sun about it.
[1] http://www.derkeiler.com/Newsgroups/microsoft.public.platformsdk.security/2003-12/0349.html
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4210047
source to share
I'm not a Citrix expert, but I know someone who is, and who has a clue:
Accounts can be configured such that read / write applications are redirected to non-local resources. The latency you are experiencing could be due to the initialization or performance of this permission.
Another possibility is that application isolation can be valid, which means that the files are read / write in virtualized versions of the resources.
source to share