tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java
Date Wed, 11 Apr 2001 22:29:07 GMT
estutes@eas.san-jose.ca.us wrote:
> As pointed out by someone else, at some point on a system that is not
> busy processes will hang on /dev/random waiting for their next chance to
> catch some randomness generated by things like mouse moves.  And if you
> are on a server, the mouse may never move. There will be other trips
> into the kernel, but I think a better strategy would be to get a random
> seed and close your particular connection.  What do you think?

I think I've covered that one in one of my other e-mails, but here is
the summary:

- we should document this properly so that all users can make an
informed decision (*very important*, otherwise there's going to be tons
of e-mail about sudden hangs of Tomcat if this was a bad idea) - if I'm
pointed towards the right document I'll submit a patch

- on a real life server the requests to Apache/Tomcat are coming through
network cards which generates 'kernel noise' and therefore /dev/random
shouldn't really block; you don't have to move the mouse or touch the
keyboard to get random data, any kernel driver counts (I just verified
that by pinging my Linux box from another box); usually the disk is
touched as well when you hit the web pages

- the next problem might be a heavily loaded box (ie. will there be
enough random data for all sessions) - usually on a heavily loaded
machine there will be plenty of random data, so I don't think heavily
loaded boxes should be an issue

- I don't think that opening and closing the /dev/random would make much
difference except for the fact that opening/closing might generate some
random data in the kernel; I'll give here one bad scenario with
/dev/random being constantly opened/closed: we open the /dev/random
(let's say this generates some random data) and then attempt to read
that data, but there wasn't generated and the read blocks - back to
square one :-(

Having said all that, it is my belief everyone should test this in their
particular situation to verify if this approach is good for them or not.
Although I can qualify as a Linux user and hardly as a Linux admin, I'm
nowhere close to being a kernel expert. So all of the above could be
pure BS (did you notice these are my initials - funny, ha ;-)

Bojan

Mime
View raw message