Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Sorry, I forgot to insert some words in "What do you see instead?":
_A misleading warning is logged to stdout, because on *MathUtils.java:136*
System.getProperties().toString() yields ..._Original comment by moldowan.android@googlemail.com on 23 Jan 2012 at 9:31
GoogleCodeExporter
commented
8 years ago Hi,
Thanks for reporting this issue. MathUtils.generateAlternativeSeed is only used
if the following code takes more than 200 ms:
SecureRandom.getInstance("SHA1PRNG").generateSeed(20);
This in turn only occurs when reading from /dev/random is very slow, which is
very rare. Using UUID.randomUUID() wouldn't help because this also reads from
/dev/random. Using log4j isn't an option because the database engine can't have
such hard dependencies. Not logging isn't an option because it's a potential
security problem (insecure random seed). I will fix this issue as follows:
// environment
try {
String s = System.getProperties().toString();
// can't use writeUTF, as the string
// might be larger than 64 KB
out.writeInt(s.length());
out.write(s.getBytes("UTF-8"));
} catch (Exception e) {
warn("generateAlternativeSeed", e);
}
Original comment by thomas.t...@gmail.com on 24 Jan 2012 at 8:01
GoogleCodeExporter
commented
8 years ago Thanks for the quick response and the explanations!
This explains why we didn't see this exception in the past: We are currently
experiencing less than stellar performance from out Hudson CI machine which
runs the tests. So this is why the fallback kicks in (more often).
Fix looks ok to me.
I respect your decision to not use a logging framework.
slf4j and logback might be worth a look, nevertheless. ;)Original comment by moldowan.android@googlemail.com on 24 Jan 2012 at 10:16
GoogleCodeExporter
commented
8 years ago Should be fixed in version 1.3.164
> slf4j and logback might be worth a look, nevertheless. ;)
Actually SLF4J is supported, but it's optional - see
http://www.h2database.com/html/features.html#other_logging
Possibly reading from /dev/random is slow on your machine? That could cause
other Java programs to slow down a lot - but I'm not sure if there is a
workaroundOriginal comment by thomas.t...@gmail.com on 3 Feb 2012 at 2:18
GoogleCodeExporter
commented
8 years ago Fix confirmed, thanks!
It seems like /dev/random isn't producing anything, whereas /dev/urandom does
produce a lot of bytes.
Maybe we need something like: http://www.vanheusden.com/te/Original comment by moldowan.android@googlemail.com on 6 Feb 2012 at 7:09
Original issue reported on code.google.com by
moldowan.android@googlemail.comon 23 Jan 2012 at 9:27