注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风之人生

人生如风,却无法如风般潇洒。

 
 
 

日志

 
 
关于我

一介草民,苟活于上海滩,以甲骨文为生,偶尔对一些国家大事有些兴趣,日常无事常以丝竹之声为乐。

网易考拉推荐

Java to Oracle failed when using random number  

2013-12-27 10:59:38|  分类: Oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Today I got one guy saying he's got the problem when he tries to do the connection test for his program written in Java. He always has some connection to Oracle failed but didn't know why.

   After carefully reviewed his program, we found that he's using some random generating method of Java in his program, such like java.security.SecureRandom, which is the standard API in Java, Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during login. Users using Linux have been encountering SQLException("Io exception: Connection reset").

The problem is two fold

1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when
SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the
method takes a long time to respond and hence cause the server to timeout

2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException("Io exception: Connection reset")


   Actually we often get this error because of the latter, because we know that in the Linux box, we use /dev/random or /dev/urandom  file for the random number generator. From the Linux kernel site we can get that:

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool.  The generator also keeps an estimate of the number of bits of noise in the entropy pool.From this entropy pool random numbers are created.

     When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

     A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist.  If this is a concern in your application, use /dev/random instead.


So we can get one solution for this is error is  using the /dev/urandom instead of /dev/random by using below because former one is non-block.

rm /dev/random
ln -s /dev/urandom /dev/random

We can see this test below:

I tried to find what is behind under /dev/random, I just using the /dev/random device,


 $ time dd if=/dev/random of=1.dmp bs=1024k count=100
dd: warning: partial read (128 bytes); suggest iflag=fullblock

and I can get the process id:

majian@mjhome ~ $  ps -ef|grep dd
root         2     0  0 07:32 ?        00:00:00 [kthreadd]
nobody    1268   995  0 07:32 ?        00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d
root      1680     1  0 07:32 ?        00:00:00 /usr/sbin/winbindd -F
root      1681  1680  0 07:32 ?        00:00:00 /usr/sbin/winbindd -F
majian    1849     1  0 07:33 ?        00:00:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 9 --session
majian    1850     1  0 07:33 ?        00:00:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
majian    1856  1852  0 07:33 ?        00:00:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
majian    3166  2728  0 08:29 pts/0    00:00:00 dd if=/dev/random of=1.dmp bs=1024k count=100
majian    3254  3211  0 08:30 pts/2    00:00:00 grep --colour=auto dd

so I trace what is going on behind the scene,

Process 3166 attached - interrupt to quit
read(0, "$\\y#\265\342\242s", 1048576)  = 8
write(1, "$\\y#\265\342\242s", 8)       = 8
read(0, "\367\221\372\370\354\261\3727", 1048576) = 8
write(1, "\367\221\372\370\354\261\3727", 8) = 8
read(0, "\247\201\216\" \227\227\200", 1048576) = 8
write(1, "\247\201\216\" \227\227\200", 8) = 8
read(0, "\355\36)\266\33W\n\331", 1048576) = 8
write(1, "\355\36)\266\33W\n\331", 8)   = 8
read(0, "\35\253\311\35\243\356<\321", 1048576) = 8
write(1, "\35\253\311\35\243\356<\321", 8) = 8
read(0, "\373N\0QA\374\327O", 1048576)  = 8

And we found that the process is gathering IRC as the input, and the dd process will return if it can gather enough noises, after hang a while, our dd process finished, so we proved that the /dev/random can cause a time-out or a long-time wait if we use it.

0+100 records in
0+100 records out
1163 bytes (1.2 kB) copied, 127.55 s, 0.0 kB/s


Java program connection issue maybe caused by OS, that's pretty interesting.
// original source from Oracle-L mail list.
  评论这张
 
阅读(152)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017