-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neha,

Neha Agrawal wrote:
| i recompiled my APR 1.2.7 with /dev/urandom

Exactly how did you do this? Are you sure you did it correctly? If you
were recompiling, why not upgrade to the most recent version (1.2.12)?

| and hence recompiled Native libraries
| (because Native library builds with --with-apr-)

What other native library?

| i did not recompile the jsvc part though

You should not have to.

| Is there any other way to look to threads dump?

This is, IMO, the best way to look at a thread dump. What other way were
you expecting?

By the way, you didn't tell us /when/ you took the thread dump. Was this
during the 12 minute delay?

This is interesting:
| Thread 26595: (state = IN_NATIVE)
|  -
| org.apache.tomcat.jni.SSL.initialize(java.lang.String)
| @bci=0 (Interpreted frame)
|  - org.apache.tomcat.util.net.AprEndpoint.init()
| @bci=486, line=633 (Interpreted frame)
|  - org.apache.coyote.http11.Http11AprProtocol.init()
| @bci=26, line=116 (Interpreted frame)

Hey, look at that! SSL is initializing. Surprise, surprise.

|   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM
| 26595 tomcat6   15   0 1713m  54m  12m S    0  1.4

0% CPU? SSL init? That guy's waiting for entropy, man.

During that long pause, try using either lsof or fuser to find out what
files are being used. This is what fuser gives me on my system:

$ fuser -uv /dev/urandom
~                     USER        PID ACCESS COMMAND
/dev/urandom:        chris      3047 f.... (chris)java
~                     chris     14835 f.... (chris)java
~                     chris     17679 f.... (chris)java
~                     chris      7658 f.... (chris)java
~                     chris     10825 f.... (chris)java
~                     chris      4176 f.... (chris)java

lsof gives me similar output:

$ lsof | grep '/dev/urandom'
java       3047 chris    4r      CHR        1,9            1446631
/dev/urandom
java       3047 chris    5r      CHR        1,9            1446631
/dev/urandom
java       4176 chris    4r      CHR        1,9            1446631
/dev/urandom
java       4176 chris    5r      CHR        1,9            1446631
/dev/urandom
java       7658 chris    4r      CHR        1,9            1446631
/dev/urandom
java       7658 chris    5r      CHR        1,9            1446631
/dev/urandom
java      10825 chris    4r      CHR        1,9            1446631
/dev/urandom
java      10825 chris    5r      CHR        1,9            1446631
/dev/urandom
java      14835 chris    4r      CHR        1,9            1446631
/dev/urandom
java      14835 chris    7r      CHR        1,9            1446631
/dev/urandom
java      14835 chris    9r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   10r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   11r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   15r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   16r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   18r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   19r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   20r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   21r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   22r      CHR        1,9            1446631
/dev/urandom
java      14835 chris   23r      CHR        1,9            1446631
/dev/urandom
java      17679 chris    4r      CHR        1,9            1446631
/dev/urandom
java      17679 chris    5r      CHR        1,9            1446631
/dev/urandom

Interestingly enough, if I use lsof to look for uses of /dev/random, I
get the same pids, but fewer uses:

java       3047 chris    3r      CHR        1,8            1444112
/dev/random
java       4176 chris    3r      CHR        1,8            1444112
/dev/random
java       7658 chris    3r      CHR        1,8            1444112
/dev/random
java      10825 chris    3r      CHR        1,8            1444112
/dev/random
java      14835 chris    3r      CHR        1,8            1444112
/dev/random
java      17679 chris    3r      CHR        1,8            1444112
/dev/random

It looks like /dev/random is used some places when when /dev/urandom is
also used. On the other hand, I'm not using APR at all.

Lessee what's in my JVM's files (I have removed comment matches in
java.security):

$ grep "/dev/urandom" `find /opt/sun-jdk-1.5.0.13/`
/opt/sun-jdk-1.5.0.13/jre/lib/security/java.security:securerandom.source=file:/dev/urandom
Binary file /opt/sun-jdk-1.5.0.13/jre/lib/deploy.jar matches
Binary file /opt/sun-jdk-1.5.0.13/jre/lib/rt.jar matches
[EMAIL PROTECTED] ~/projects/diagnosis $

So, I've configured my system to use /dev/urandom (or maybe my
distribution editors did). Let's see about /dev/random:

$ grep "/dev/random" `find /opt/sun-jdk-1.5.0.13/`
Binary file /opt/sun-jdk-1.5.0.13/jre/lib/rt.jar matches

Looks like rt.jar uses /dev/random at some point, though none of the
standard sources (found in src.zip) contain it. Interesting.

Anyhow, this was all academic: java.security, rt.jar, everything, it's
all about Java. Even -Djava.security.egd=/dev/urandom is irrelevant. You
are using APR, so none of those Java tricks will help.

The point is, unless you have configured your APR properly, you're not
going to use /dev/random. So, let's focus on that. How did you build
your APR?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAke69joACgkQ9CaO5/Lv0PAstgCfbl27d6jDIp4kxlHVAF2/UGqx
vPsAoKkVEi9kfYMpUANOR5Ugp32rfI20
=snyN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to