Thank you, Vasu. That explains it! It's amazing a bug was submitted in 2004 but updated and resolved in 2012. Yong Huang --- On Wed, 11/14/12, Vasu Balla <appsdba@xxxxxxxxx> wrote: It's a bug in Java. http://bugs.sun.com/view_bug.do;jsessionid=ff625daf459fdffffffffcd54f1c775299e0?bug_id=6202721 Java picks up /dev/random even though /dev/urandom is passed in command line. The workaround around is to trick java to use /dev/urandom, by using /dev/./urandom. Basically it's the same device, (.) dot means current directory Most Linux serves running on VMWARE or some other virtual server have problem with slow /dev/random devices Renaming random device and creating softlink is a good workaround, unless you are not a Federal Regulated Environment. Data from urandom is not as random as /dev/random device. Vasu -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Yong Huang Sent: Wednesday, November 14, 2012 12:19 PM To: oracle-l@xxxxxxxxxxxxx Subject: Difference between /dev/urandom and /dev/./urandom (Was: swingbench connection issue) > This seems to have solved it > https://kr.forums.oracle.com/forums/thread.jspa?threadID=941911 > > *rm /dev/random* > *ln -s /dev/urandom /dev/random > > > *strange that the problem arises with one database on the box but not > another on the same box I have another puzzle related to /dev/(u)random. I posted somewhere else without an answer. On RHEL 6, a very simple JDBC java program returns instantly if I pass /dev/./urandom to -Djava.security.egd (entropy gathering device). But if I pass /dev/urandom to it, or omit this option altogether (I assume it uses /dev/random), it takes a long time (unless entropy happens to have accumulated enough in the past, which doesn't happen often on this headless server). $ time java -Djava.security.egd=file:/dev/./urandom -cp .:/u01/app/oracle/product/11.2.0/db/jdbc/lib/ojdbc6.jar:/u01/app/oracle/prod uct/11.2.0/db/jdk/jre/lib TestClient <-- ojdbc5.jar behaves the same as ojdbc6 Got it. <-- this is just the output of TestClient real 0m0.848s <-- always subsecond user 0m1.064s sys 0m0.083s $ time java -Djava.security.egd=file:/dev/urandom -cp .:/u01/app/oracle/product/11.2.0/db/jdbc/lib/ojdbc6.jar:/u01/app/oracle/prod uct/11.2.0/db/jdk/jre/lib TestClient Got it. real 0m7.999s <-- anywhere from a few to tens of seconds user 0m1.041s sys 0m0.100s This is very reproducible. I can't think of any difference whether there's one more "directory" layer "." between /dev/ and urandom. Literally, it just tells the process to go to *the current* directory which is already /dev/, before it goes on to read urandom. Any thought? -- //www.freelists.org/webpage/oracle-l