-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ray,

On 10/25/17 9:08 AM, Ray Holme wrote:
> I asked this question before (differently) and got some answers but
> now I think I understand what is really happening. I just want to
> confirm that I have finally understood what is happening. Given two
> Linux boxes running the same application, one is much slower
> starting (think that  "slower" machine is actually a much faster
> box) Here are some excerpts from the catalina.out log and my
> guesses as to what is happening.If someone knows why this is
> happening for sure, I would really appreciate knowing. ----- Both
> Linux machines run 8.5.13 Tomcat
> 
> log here - fedora 26 running real (not virtual) Oct 25, 2017
> 8:38:20 AM org.apache.jasper.servlet.TldScanner scanJars INFO: At
> least one JAR was scanned for TLDs yet contained no TLDs. .... 
> application @ 10/25/2017 8:38:20 Thread:15 SecurityFilter.init :
> 
> log server - Ubuntu running virtual (suspect machine much faster) 
> 25-Oct-2017 08:43:34.283 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars INFO: At least one
> JAR was scanned for TLDs yet contained no TLDs. ...... 25-Oct-2017
> 08:45:00.151 INFO [localhost-startStop-1]
> org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom
> Creation of SecureRandom instance for session ID generation using
> [SHA1PRNG] took [85,739] milliseconds. application @ 10/25/2017
> 8:45:00 Thread:15 SecurityFilter.init :
> 
> 
> Both boxes have same list for jar scan skipping - includes all
> application jars used (had all tomcat jars already).Note that my
> machine use NO time to get on with it, but 1.5 minutes is used for
> the server.
> 
> I had an error in the scan skip lines and the time above was 10.5
> minutes till I fixed it so I know CATALINA_HOME is right. (left off
> a comma in middle of list, so it scanned a lot of jars - :=[ ).
> 
> I suspect the performance problem has nothing to do with jar
> scanning but has to do with the real (and virtual) server running
> with https not http for secure login (my development machine behind
> firewall with no external access) - perhaps the SecureRandom is the
> thing that is making this slow.

Yes, it's the SecureRandom initialization that is killing you. Being a
virtual server, it likely has no direct source of true randomness so
it needs to pull from whatever the hypervisor is willing to provide.

You'll need to ask your virtualization vendor for how to get access to
more entropy, or switch to a less-secure random source (e.g.
/dev/urandom on *NIX-like systems).

I'm not sure if these is consensus amongst security-minded individuals
as to whether or not using /dev/urandom is okay to do. If you are
generating long-lived key material (e.g. RSA, ssh, etc. keys) then I
think the answer is a definitely DO NOT USE. But for things like
session ids (which is the application in this case), IMO it's
reasonable to use this less-secure source of entropy.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnwj3QACgkQHPApP6U8
pFiv3xAAx/rxCxxwupWCbBqb21w6sby83EZtz0JkmCKaZYESnQ1mAHWmMbHWjJfN
EdH5dURsjPMP4lzrXNJTXUZYJW23ieWOMLycKeyXCzpFiqXBJ2nnremxOKKwhbBn
Xm/6U9CCtF2Ioextsqipk0WkuPWDnmyUkNOns/MVTBuy3A94RgTuIJiC0TRjMTsd
c6/9VuzSi0yBMf/xdpBZ47JmTM2ybojzBfSWHObynKjl+CDB9jx7GjXMxr2tIZ5d
D7kFTopD4QT9O12AbRX1lujfQMHCd1142GVfHrzSajCA31+ap0PAhPVTMWxFBhrC
F+Y/nnWoGR9yScMsbf+oVYLVFNeIdOmBVYaNJSF9d5YTaMdUc/0v4TDEa8Da6hE1
s42CpCHIUojtkzrMLFmex+MdumsJwISF8NbvPgrzpjY3phvTR/Xe4+XlUgvkFse/
i9fvf/9fH7ARMul5g/XVD1vVH8N3Sg/YjJ/8gqno85hK/Im6mQbaX9z6sFRhhcYd
+jt1+n5n661KhKGlkIzDxCbYxvU17c940umdiqLxWUUQp8oq9Ra7dvr+hVdpU1lC
ZWGYYwuufcemZ66KLoafgswlD9dIxrrx1cehFwcFbLixW2hmAOfG2zgZ+Mvmrcj9
NlYkeDhijbnK8P/8ixThfHNtGmtoDpTPnGJZ5kPvLrP90E2EpUI=
=YSRO
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to