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的作用。

該測試結果和原先的猜想基本符合。但是性能評估很容易得到片面的結論，如果有錯誤的地方，請大家不吝指正。謝謝。