RandomUtils.getSecureRandom() creates a thread that never exits causing an embedded H2 database to hang.

[GoogleCodeExporter]

What is the problem?
On a linux machine with sufficiently low entropy, a call to
java.security.SecureRandom.generateSeed(20), as in line 43 of RandomUtils,
will block until it has read 20 bytes from /dev/random. When using H2 as an
embedded database, the RandomUtils.getSecureRandom() function will create a
thread that may never exit. This thread may never exit, causing any JVM
using H2 to hang for an indeterminate amount of time.

What steps will reproduce the problem?
The problem is reproducible on a linux box with sufficiently low amounts of
entropy. The problem occurred on a i86pc running RHEL3. In particular, a
machine that will hang after several calls to "cat /dev/random". 

What version of the product are you using? 
The bug exists in at least 1.0.65, 1.0.66, 1.0.67, and trunk. 

Do you know a fix?
The problem is that the thread created in RandomUtils.getSecureRandom() may
never exit causing any JVM using H2 to run until /dev/random has yeilded 20
bytes to the H2 thread. No guarantee can be made about when this will occur
- it may take several days as our testing has shown. The easiest fix would
be to add "t.setDaemon(true)" to this thread so that it does not prevent
the JVM from exiting. However, this is a rather weak solution that avoids
the heart of the problem. A quick attempt at adding "t.interrupt()" after
line 59 "t.join(400)" did not fix the problem - the InputStream that is
reading from /dev/random does not seem to be interruptable. A true solution
should somehow kill the thread after a timeout (perhaps impossible in java)
or avoid the use of java.security.SecureRandom.generateSeed(20) since no
guarantees can be made for when it will return. 

How important/urgent is the problem for you?
Extremely urgent. This determines whether or not H2 can be used as an
embedded database on all our supported platforms. 

In your view, is this a defect or a feature request?
Defect.

Please provide any additional information below.
H2 has looked really great on all other aspects - its performance blew most
other competition out of the water and scaled very well to handle millions
of rows in a table. We would really love to put it to use as an embedded
database, but we simply can't use it if it will cause the whole JVM to hang
on certain systems. Please let me know if you can find a good fix for this
or if you need help testing your solution. Thanks a lot!

Original issue reported on code.google.com by matthew....@gmail.com on 26 Feb 2008 at 8:49

[GoogleCodeExporter]

Hi,

I think not having a 'true' random seed is a problem, and using the alternative
algorithm should not be the only way. So starting the thread (at least trying 
to get
a real random seed) is important for security. You wrote: "The easiest fix 
would be
to add "t.setDaemon(true)" to this thread". Does this actually work? If yes I 
think
this would be the best solution (even if it's a bit ugly, I agree).

Original comment by thomas.t...@gmail.com on 27 Feb 2008 at 5:13

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

"I think not having a 'true' random seed is a problem". Yes, you're definitely 
right. 

Adding "t.setDaemon(true)" does fix the problem - I tested it out on the machine
causing the problems. The reason is that it "Marks this thread as either a 
daemon
thread" and since "The Java Virtual Machine exits when the only threads running 
are
all daemon threads" this thread will not cause the JVM to hang even if it is 
still
running when we try to shutdown an embedded database and exit. 

In retrospect I guess it's not really a terrible solution. In particular, this 
will
still ensure the highest level of security possible for each machine on which
SecureRandom.generateSeed(20) is working fine. 

Original comment by matthew....@gmail.com on 27 Feb 2008 at 2:24

[GoogleCodeExporter]

It is committed in the trunk and will be included in the next release (in about 
two
weeks).

Original comment by thomas.t...@gmail.com on 28 Feb 2008 at 7:07

[GoogleCodeExporter]

Wow! That was quick. Thanks a lot!

Original comment by matthew....@gmail.com on 3 Mar 2008 at 2:29

[GoogleCodeExporter]

Fixed in version 1.0.68

Original comment by thomas.t...@gmail.com on 15 Mar 2008 at 11:19

• Changed state: Fixed