I changed securerandom.source=file:/dev/random in /jre/lib/security/java.security, changing this to urandom and it vastly improved things. My question is, what will this do? I don't really rely on the tomcat generated session affinity ..
On 7/28/19, John Dale <jcdw...@gmail.com> wrote: > Greetings; > > I found this in the logs where it's hanging-up: > > 28-Jul-2019 19:05:10.520 WARNING [main] > org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom > Creation of SecureRandom instance for session ID generation using > [SHA1PRNG] took [212,424] milliseconds. > > Thoughts? > > John > > > On 7/27/19, Christopher Schultz <ch...@christopherschultz.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> John, >> >> On 7/27/19 19:49, John Dale wrote: >>> Greetings Everyone; >>> >>> A quick update to the folks who I have interacted with on the list >>> (you know who you are and I thank you). >>> >>> I got all of my applications and sites migrated from Tomcat 7.x.x >>> to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work >>> with the firewalls, databases, and email servers (DKIM, SPF, and >>> DMARC are something else). >>> >>> Overall, I was kind of disappointed to find out that Java 11 >>> doesn't include activation and jax libs, but it sure was fast once >>> I included these things in my lib folder. That said, I thought it >>> might be better to revert to Java 8, which bundles and unit tests >>> these libraries. So, that's what I did. >>> >>> But yikes .. the startup times are now very slow .. sometimes two >>> minutes. I understand that this might relate to the need of the >>> JVM to initialize for random number seeding. Is this true? >> >> What makes you say that? It might be correct, but you are just >> providing a guess, here. >> >>> What other strategies should I be looking at to make the bounce >>> more zippy? I deploy two smallish war files (<5MB, about 160KB >>> Java Services code) >> >> Note that the size of the code is largely irrelevant. >> >>> I noticed several recommendations for different random number >>> seeding strategies, but they came with warnings relative to the >>> quality of encryption. What else might be done that doesn't >>> compromise encryption quality? >> >> Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by >> default which is safe enough to use for probably everything but >> long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP >> keys, etc.). You probably shouldn't be generating long-lived keys of >> these kinds from within a Tomcat-hosted application. /dev/urandom is >> non-blocking so it shouldn't stall when grabbing entropy for things >> like random-number seeding (which are used by Tomcat for both random >> session-id generation and random TLS bulk-encryption keys. >> >>> I would like to push back my Java 11 upgrade until I have a good >>> longer term strategy for jax and activation libraries. Thoughts? >> >> Why not simply bundle those required libraries with your application? >> >>> Glad to have made it through the upgrade .. it really wasn't very >>> painful at all. >> >> Glad to hear it wasn't painful. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 >> pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z >> QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy >> plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp >> uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ >> sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq >> vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 >> b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 >> uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy >> dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT >> joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt >> St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= >> =Qhtz >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
