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:
>> 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 - https://www.enigmail.net/
>> 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

Reply via email to