wueddie

during analysis of "IO Error: Connection reset", many articles mentioned that it could be caused by java security code (accessing /dev/random) used in JDBC connection. However it is not the root cause in my case. In my environment, Java already use /dev/urandom. 1. $JAVA_HOME/jre/lib/security/java.security securerandom.source=file:/dev/./urandom 2. check with strace. only -Djava.security.egd=file:/dev/../dev/urandom will trigger system call (read on /dev/urandom) all other other path format like below are OK. -Djava.security.egd=file:/dev/./urandom -Djava.security.egd=file:///dev/urandom 3. Keep checking the retropy size, I have never seen it is exhaused. while [ 1 ]; do cat /proc/sys/kernel/random/entropy_avail sleep 1 done usually the avail is in the range from 1000 to 3000. so far, there is no clue about the root cause of "IO Error: Connection reset".

I encountered many issue during installation of Oracle Grid Infrastructure(GI) and Database; with the help of ariticle and documents found through Google search engine, I finally made it. for records, here is the details issues encountered and solutions applied. Major issues were encountered during GI installation. Pre-installation tasks. Issue 1: swapspace is not big enough; (1.3.1 Verify System Requirements) grep MemTotal /proc/meminfo 264G grep SwapTotal /proc/meminfo 2G during OS installation, I take default option and swap space is only 2G. Oracle recommend to have more than 16G swap space in case of more that 32G RAM. dd if=/dev/zero of=/home/swapfile bs=1024 count=33554432 33554432+0 records in 33554432+0 records out 34359738368 bytes (34 GB) copied mkswap /home/swapfile mkswap /home/swapfile chmod 0600 /home/swapfile lessons learned: setup swap space properly according to DB requirement when installing OS. Issue 2: cannot find oracleasm-kmp-default from Oracle site. (1.3.6 Prepare Storage for Oracle Automatic Storage Management) install oracleasmlib and oracleasm-support is easy, just download them from Oracle and install them; Originally oracleasm kernel is provided by Oracle, but now I cannot find it from Oracle; finally I realized that oracleasm kernel is now provided by OS vendor; In my case, it should be installed from SUSE disk; a. to get its name oracleasm-kmp-default zypper se oracle b. map dvd and install zypper in oracleasm-kmp-default rpm -qa|grep oracleasm oracleasm-kmp-default-2.0.8_k3.12.49_11-3.20.x86_64 oracleasm-support-2.1.8-1.SLE12.x86_64 oracleasmlib-2.0.12-1.SLE12.x86_64 asm configure -i asm createdisk DATA /dev/<...> asm listdisks --DATA ls /dev/oracleasm/disks Installation tasks: Issue 3: always failed due to user equivalence check after starting installer OUI with user oracle. however if I manully check with runcluvfy, no issue found at all. ./runcluvfy.sh stage -pre crsinst -n , -verbose I worked around it by using another user to replace user oracle. but it triggered next issue. Issue 4: cannot see ASM disks in OUI. no matter how I change the disk dicovery path. the disk list is empty. but I can find disk manully. /usr/sbin/oracleasm-discover 'ORCL:*' Discovered disk: ORCL:DATA Root cause is that the ASM is configured and created with user oracle. and I aming installing GI with different user other than oracle; so I cannot see the Disk created. change owner of disk device file solved the issue. ls /dev/oracleasm/disks chown /dev/oracleasm/disks -R Issue 5: root.sh execution failed. Failed to create keys in the OLR, rc = 127, Message: clscfg.bin: error while loading shared libraries: libcap.so.1: cannot open shared object file: No such file or directory fixed the issue with command below: zypper in libcap1 ohasd failed to start Failed to start the Clusterware. Last 20 lines of the alert log follow: 2016-07-24 23:10:28.502: [client(1119)]CRS-2101:The OLR was formatted using version 3. I found a good document from SUSE, Oracle RAC 11.2.0.4.0 on SUSE Linux Enterprise Server 12 - x86_64, it make it clear that SUSE 12 is supported by Oracle GI 11.2.0.4, it also mentioned Patch 18370031. "During the Oracle Grid Infrastructure installation, you must apply patch 18370031 before configuring the software that is installed. " The patch 18370031 is actually mentioned in "Oracle quick installation guide on Linux", but not mentioned in "Oracle quick installation guide on Linux". I majored followed up with later one and missed Patch 18370031. issue disappeared after I installed the patch 18370031. ./OPatch/opatch napply -oh -local /18370031 Errors in file : ORA-27091: unable to queue I/O ORA-15081: failed to submit an I/O operation to a disk ORA-06512: at line 4 solved by change owner of disk DATA related file ls -l /dev/oracleasm/iid chown on folder /dev/oracleasm/iid and some .* hidden file. Issue during DB installation Issue 6: report error: in invoking target 'agent nmhs' vi $ORACLE_HOME/sysman/lib/ins_emagent.mk Search for the line $(MK_EMAGENT_NMECTL) Change it to: $(MK_EMAGENT_NMECTL) -lnnz11 refer to https://community.oracle.com/thread/1093616?tstart=0

很多年前装了Ubuntu和Windows的双系统，最近因为有了专门的电脑来装Ubuntu，所以把原先电脑上的Ubuntu卸载了，结果系统不能引导了。因为GRUB的原理是控制权从MBR到Ubuntu系统盘，然后Ubuntu系统盘再提供对windows的引导。现在Ubuntu系统被卸载了。这个启动的链条也就断了。

这个问题本身不难解决，借了一个Windows安装盘，恢复一下MBR即可。但是这个需要windows系统的Administrator密码。而我的系统不是我装的，我根本不知道这个密码。

有的帖子提到破解Administrator密码，试了一下，觉得太麻烦了。因为电脑上有数据，也不能重装。 

最后的解决方案是在原先的Ubuntu分区上安装一个新的Windows。这样变成了windows的双系统。安装完重启之后可以进入任何一个系统（新的或者旧的Windows）。安装的过程中MBR被自动更新了。再下来就改一下老系统的Administrator密码，删除掉多于的Windows新系统即可。

用Gmail的时候不小心点了"存档"按钮，一封重要的邮件就此消失了好几天，今天才机缘巧合找到。

在网络上查到的解释是：
        存档会将邮件从收件箱移至所有邮件，这样您不必删除邮件就可以整理收件箱。

难以理解，坦率地说，这个功能对我来说是徒增烦恼。看来任何工具都需要你去适应，磨合。

最近买了一个叫做“华容道”的玩具给儿子晚。这个游戏虽然号称是中国四大古典智力游戏之一。其实不过百年历史，而且是从国外引进的。不过本地化做得非常好，也算是创造性地吸收国外文明。

手工解决这个游戏有点难度，当然已经有人给出了解法；不过我还是自己用编程的方式解决了一遍。发现自己在这方面的编程还是比较弱。大部分时间花在了调试上。

刚开始是用的深度优先搜索。大致知道了答案应该长什么样。后来改进为广度优先搜索，得到了最优的解法。还有一个就是原先只考虑每次最多移动一格。后来发现传统的定义是一个块的所有连续移动都算作一步。相应地修改了实现算法。

最难的是做界面。为了调试，随便写了个Applet。但是给我儿子玩，就觉得拿不出手了。

Just use this blog to share some meta information.


  

git://github.com/ueddieu/mmix.git

After two weeks' struggle, I have successfully installed Gentoo, a popular GNU/Linux Distribution. For Records, the obstacles I encountered are listed below. (but I can not remember the solution exactly)

0. failed to emerge gpm when I install the links package. If I recall correctly, it is resolved by install gpm manually

1. I encounter issue when I install glib 2.22.5. no update-desktop-database. which is in dev-util/desktop-file-utils. When I try to emerge it, there is a circular dependency on glib. no solution and I forget How I resolve the problem.

2. later after I install glib, with ~amd64 keyword I can install gpm-1.20.6, but it conflicts with the manually inatalled gpm. I remove the conflicted file and emerge successfully.

3. Failed to emerge tiff. edit packages.keywords to add the following. / ~amd64 I am able to use latest tiff in beta-version, which is unstable and masked out.

4. later atk-1.28.0 failed to emerge. edit /etc/make.conf with the following. FEATURES="-stricter". then emerge successfully with only some complain. with out this seting. the warining from GCC will cause that emerge fail.

5. when I run emerge --update system actually gcc will be upgraded from 4.3.4 to 4.4.3. but it failed because of compilation warning, again. add "-stricter" into Features variable in /etc/make.conf work around it.

6. The installation takes a long time, the KDE itself take more than 10 hours. There is still a lot of improvement space! Anyway, it is nice to be able to use it daily.

在C:\Documents and Settings\<user_name>\Application Data\Subversion\servers文件中加入
all=*.*

[all]
http-proxy-host = ***.**.com
http-proxy-port = 8080

这里的all映射到所有的Server。

网络环境的复杂给我们的工作带来了一些影响。就拿Proxy的设置来说，本来理想的情况是在全局做一个设置就可以了，但是事实上我们要为每个程序做设置，而且语法还不一样。

今天从word文档中拷贝脚本到命令行执行。没有想到的是Word自动加入了空格，导致执行失败。具体如下。
call ttGridCreate('$TT_GRID');
被word变成了
call ttGridCreate(' $TT_GRID');
这个空格可不容易被发现，尤其你不是脚本作者的时候。提高警惕！

今天做了一个简单的性能测试。比较访问Java对象属性的各种方法的性能差异。
1. 直接访问对象的属性。
2. 用方法访问对象的属性。
3. 用Map来存储和访问。
4. 反射－Field 访问。
5. 反射－Method访问。

重复100次，结果如下(单位为纳秒）。
 * 100 field access, 14,806<br/>
 * 100 method access, 20,393<br/>
 * 100 map access, 66,489<br/>
 * 100 reflection field access, 620,190<br/>
 * 100 reflection method access, 1,832,356<br/>
重复100000次，结果如下(单位为纳秒）。
 *100000 field access, 2,938,362
 *100000 method access, 3,039,772
 *100000 map access, 10,784,052
 *100000 reflection field access, 144,489,034
 *100000 reflection method access, 37,525,719 <br/>
 
由结果可见：
1。getter/setter 的性能已经接近直接属性访问（大约慢50％），没有必要担心getter/setter的性能而采用直接属性访问。
2。用Map代替POJO的代价大约是比getter/setter慢三倍。
3。反射访问比getter/setter慢50到150倍。慎用。追求动态性的时候也要注意不菲的性能代价。
4。注意重复次数增加到100000次，方法访问和属性访问的差距缩小；更有意思的是，反射的Method访问比Field访问快四倍。这主要是JIT的作用。

该测试结果和原先的猜想基本符合。但是性能评估很容易得到片面的结论，如果有错误的地方，请大家不吝指正。谢谢。