Greetings; 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.
After reading up on the issue and searching around for a few hours, I found many posts like these folks falling all over themselves recommending haveged: https://www.digitalocean.com/community/questions/fresh-tomcat-takes-loong-time-to-start-up > >> 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. Correct .. unless there are huge jar files with many many classes to scan for deployment metadata? In my case, I have a very robust little application in a tiny deployable, so I was ruling that out. > >> 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 assume you mean "long-lived"? :D I don't believe I'm generating these, but in my survey of online information it seemed to indicate Tomcat might be doing this for some of its own internal processes. You would know better than I would if this is true. At some point I'd like to get into the Tomcat source code, probably after what I have now is hardened and virtually unchanging. But then, that's why we have you, right? :) I'm deploying ssl certs from certbot into a pfx type deployment. Maybe this is related to the issue? > >> 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. Just this startup issue. I like to be able to make quick changes, and faster start times are way more fun. I'm just stumped as to why Java 11 seemed to be so much faster to startup the same code base. I'll keep poking around. If you have any ideas please let me know. Thanks! John Dale DB2DOM > > 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
