Good morning, ibm i platform, but I think on windows or linux there would be the same error. I only encounter the problem on one application and not the others, when tomcat stops an error is written in the log, I do not encounter any problem with tomcat 9.10 error : 04-Apr-2023 14:27:08.822 AVERTISSEMENT [http-nio-81-exec-7] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [planning] semble avoir démarré un thread nommé [SeedGenerator Thread] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est : java.base/java.lang.Object.wait(Native Method) java.base/java.lang.Object.wait(Object.java:190) java.base/sun.security.provider.SeedGenerator$ThreadedSeedGenerator.run(SeedGenerator.java:332) java.base/java.lang.Thread.run(Thread.java:839) Cordially.
It's mostly a warning (which can be disabled). This thread was apparently started while the context CL was set to the app's, and so that causes a leak if you reload the said app. This can happen if somehow the random has not been used before going into the app and it uses it first, and if the internal seed provider is being used. I don't quite understand how that can happen since the default manager will initialize and use the session id generator on start. The thread should be started at that point. Please provide the Tomcat configuration used (server.xml). "I think on windows or linux there would be the same error" Actually, it would be far more likely to rely on OS provided features in that case (you can read the JDK sources), so no I don't think the issue will occur.
Created attachment 38531 [details] server.xml
(In reply to SESAME from comment #2) > Created attachment 38531 [details] > server.xml Thanks. So after reviewing it, the issue is caused by the fact that the session id generator is always created during start in the webapp classloader context (other platforms won't see any issue since they would simply use the system seed, it seems yours would not and creates that seed thread). While it would be possible to make the context switch more precise, it is mostly a waste of time IMO. The most reasonable option would be to init this ahead of time. Maybe something like getting some bytes from a Random in StandardServer.initInternal, or something like that, would be the best plan.
This can be initialized early by using the SecureRandom to generate a seed. I added an initSeedGenerator attribute on the JreMemoryLeakPreventionListener (set it to true) to do that. I don't know exactly which platforms would need it. Let me know if this is not fixed. The change will be in 11M5, 10.1.8, 9.0.74 and 8.5.88.
Thank you for your answer, I will wait for the release of version 9.0.74, do you have a date ?
Please do not re-open fixed issues.
(In reply to SESAME from comment #5) > Thank you for your answer, I will wait for the release of version 9.0.74, do > you have a date ? Have a look at the release history for Tomcat 9 and set your expectations accordingly.