Reviewing testsuite logs when running on Windows, I noted the following error messages:

<date, time> org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/foo] appears to have started a thread named [SeedGenerator Thread] but has failed to stop it. This is very likely to create a memory leak.

The above warning is from org.apache.catalina.authenticator.TestDigestAuthenticator, but there are other test cases that display it.

This is observed when testing on Windows 7 using
Tomcat 8.0.3 +Oracle Java 7u51 (32-bit)
Tomcat 7.0.52 +Oracle Java 6u45 (32-bit)
Tomcat 7.0.52 +Oracle Java 7u51 (32-bit)


Googling by the thread name, I found openjdk7 source code for sun.security.provider.SeedGenerator class at [1]

[1] http://www.docjar.com/html/api/sun/security/provider/SeedGenerator.java.html


To reproduce on an usual Tomcat instance, on Windows:
1). Create bin/setenv.bat:

set CATALINA_OPTS=-Djava.security.egd=file:/dev/./urandom

2). Start Tomcat. Note what web application was deployed and started first. In my case it is "docs".

3). Trigger reload or redeploy of the web application (touch its WEB-INF/web.xml, or rename docs -> docs1).

After this, an "appears to have started a thread named [SeedGenerator Thread]" message is logged in catalina.<date>.log file.

(It does not matter whether the application actually generates session ids. It matters that it was the first to start session id generator).



My conclusion:
===============
1. This is triggered by the following setting in build.properties.default file:
test.jvmarg.egd=-Djava.security.egd=file:/dev/./urandom

If the file "/dev/urandom" is not readable (e.g. on Windows, may be on some unix systems as well), SeedGenerator fallbacks to an algorithm that creates that "SeedGenerator Thread" thread.

2. Workaround:
Redefine this property in custom build.properties file.
Using any 1 of the following 2 lines works. The message disappears from test logs.

test.jvmarg.egd=-Djava.security.egd=file:/dev/urandom

test.jvmarg.egd=

(The "file:/dev/urandom" value is considered by SeedGenerator class as a special value, a marker to use native implementation of random seed generator).


Possible fixes:
================
1. Document this effect in places where "java.security.egd" property is mentioned.

A web application should not use such value of "java.security.egd" property when /dev/urandom is not readable.

(I know two places: Migration guide, "FasterStartUp" wiki page)

2. Fix configuration of the tests.

Maybe either document this in testing section of BUILDING.txt,
or move this property definition into build.xml, making it conditional on <available file="/dev/urandom">.

3. Can JreMemoryLeakPreventionListener guard against this?
Maybe it can, by creating a SecureRandom instance.

Generally, I see no need for such guard there, because trying to use /dev/urandom on a system where such file is not readable  is a blatant configuration error.


4. Can clearReferencesThreads turn a deaf ear to SeedGenerator thread?

I think it should not. I think it is a read issue that pins TCCL in memory.