Just remembered seeing some classes in JCS that had Blocking in the name. Maybe it is intentional to use that SecureRandom implementation.
In which case I think the best option would be to re-write the test that fails on environments where /dev/random is slow. Cheers Bruno Sent from Yahoo Mail on Android On Fri, 31 Dec 2021 at 10:05, Bruno P. Kinoshita<brunodepau...@yahoo.com.br.INVALID> wrote: Hi, Thomas has had a lot of patience troubleshooting this issue with me off-list (thanks heaps!). Not only remotely, but I think we are on opposite timezones too. Yesterday Thomas suggested to look at EncryptingSerializer, and also to look at the time that my machine was taking to get data from /dev/random. Turns out that was a good suggestion, as /dev/random is very slow on my old Thinkpad (maybe some daemon that I disabled, or another BIOS/OS setting?. It never caused any issue on my environment - that I could notice, at least. But for Commons JCS the unit tests take a very long time to run. The call to this.secureRandom.nextBytes() in EncryptingSerializer takes about 1 minute. I configured my JVM with the java.security configuration file to use /dev/urandom, but the tests still failed. Tried /dev/./urandom (found it in some Tomcat docs) but it made not difference. Looking at EncrytpingSerializer, it calls SecureRandom.getInstanceStrong(). With a debugger, I confirmed that it returned a NativePRNGBlocking, which states in its docs that it uses /dev/random. Changing that to `this.secureRandom = new SecureRandom()` the tests for me pass with `mvn clean test install site` in 5-6 minutes, with no issues. I had a quick look at commons-rng, and saw that it uses `SecureRandom secureRandom = new SecureRandom()`. Looking at that constructor docs, it appears that it chooses the best random generator based on the list of available providers. So maybe replacing `SecureRandom.getInstanceStrong` by `new SecureRandom()`, and documenting to users that they must specify the best option for their environment, preferably one that generates random-enough data, could be an improvement for a next release? (didn't have time to dig more and see the implications of doing so, maybe others here have more experience, other ideas?) I didn't have time to look if that `.getInstanceStrong` was introduced in this release, but if not, and since no users are reporting any issues with that, I guess it is not a blocker? Assuming that's correct, I'll leave my +1 here. And thank you again, Thomas! Cheers Bruno On Thursday, 30 December 2021, 04:12:03 am NZDT, Thomas Vandahl <t...@apache.org> wrote: > Am 29.12.2021 um 16:06 schrieb Gary Gregory <garydgreg...@gmail.com>: > > Is this test failure being addressed? Well, "addressed" is a big word for what I'm currently trying. "looked at" is closer to what happens. Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
