Xuelei Fan wrote: > Max, > > I'm not satisfied with the fix, it try to read the *first* 1024 files in > the "java.io.tmpdir", I don't know the order of the iterator of > java.nio.file.Path.newDirectoryStream(), but if the order sounds like by > name, by creation time, etc. I don't think the randomness is strong enough.
Correct. On a server with too many tmp files not get deleted, the first 1024 will always be the same. New webrev: http://cr.openjdk.java.net/~weijun/6705872/webrev.01/ Now I choose the file for random. To be 100% identical to the old codes when there are not many files, I always choose the first 512 files. > > We talked about the bug around July, 2008 (Subject: SHA1PRNG > SecureRandom architecture). Brad suggested remove the java.io.tmpdir > stuff completely, while I think maybe we need the randomness of them. We > got no conclusion on the discuss. > > I would prefer remove the stuff now. Well, I don't know. More random facts bring more randomness, and I dare out remove any of them without a theoretical computation. Thanks Max > > Thanks, > Andrew > > Weijun Wang wrote: >> Hi All >> >> A code review request for >> >> 6705872 SecureRandom number init is taking too long >> on a java.io.tmpdir with a large number of files. >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6705872 >> >> Webrev is at: >> >> http://cr.openjdk.java.net/~weijun/6705872/webrev.00/ >> >> The threshold 1024 is a randomly chosen big enough number. >> >> Thanks >> Max >> >
