I found this in the logs where it's hanging-up:

28-Jul-2019 19:05:10.520 WARNING [main]
Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [212,424] milliseconds.



On 7/27/19, Christopher Schultz <> wrote:
> 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
> Comment: Using GnuPG with Thunderbird -
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to