Message-ID: <117660597.300534.1369055965473.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_300533_1806975153.1369055965473" ------=_Part_300533_1806975153.1369055965473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The HashSessionIdManager class by default will use the java.security.Sec= ureRandom random number generator. It uses the operating system's source to= provide entropy. If your machine is very tranquil, then there may not be e= nough entropy to drive the random number generator and hence the operating = system waits for more interrupts, disk IO, network traffic or whatever is u= sed to generate the entropy.
An INSECURE solution, apart from loading the machine mo= re ,= is to replace the SecureRandom with the java.util.Random generator instead= . Add the following lines to your jetty.xml file:
Session IDs generated by Random may be able to be predicted, thus it is = not recommended to use Random in production.
For more information, here are the relevant Sun bug numbers: 6202721, 6521844, 5031872.
Note that one of the workarounds suggested is to try and force the use o= f the /dev/urandom device, which does NOT block, rather than the /dev/rando= m device which does:
NB Some workaround reports use /dev/./urandom instead of /dev/urandom.= p> ------=_Part_300533_1806975153.1369055965473--