Feeds:
文章
迴響

上次才剛玩 beta1 今天他就已經變成 RC1, 立馬更新繼續測試…

 

測試環境

  • Windows 7 x64
  • Docker 17.05.0-ce
  • VirtualBox 5.1.6
  • git 2.9.2(curl.exe, bash.ex)
  • bootstrap-1.0.0-rc1.sh

目錄結構

  • c:\docker
    • /fabric-samples
      • /bin
      • /basic-network
      • /chaincode-docker-devmode
      • /fabcar
      • /first-network

VirtualBox 共享目錄對應

  • /host : C:\docker

環境初始化

c:
cd docker
git clone https://github.com/hyperledger/fabric-samples.git
cd fabric-samples
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap-1.0.0-rc1.sh | bash
curl https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric/windows-amd64-1.0.0-rc1/hyperledger-fabric-windows-amd64-1.0.0-rc1.tar.gz | tar xz

初始化完成必要的 image

修改 *.yaml 的 volumes

  • 調整對應到 /host/fabric-samples 路徑

範例: chaincode-docker-devmode

Console1: 啟動服務

cd c:\docker\fabric-samples\chaincode-docker-devmode docker-compose -f docker-compose-simple.yaml up

Console2: 編譯/執行 ChainCode

  • 也可先用 go test 執行測試
docker exec -it chaincode bash
cd chaincode_example02
go build
CORE_PEER_ADDRESS=peer:7051 CORE_CHAINCODE_ID_NAME=mycc:0 ./chaincode_example02

執行結果

Console3: 使用 ChainCode

docker exec -it cli bash

peer chaincode install -p chaincodedev/chaincode/chaincode_example02 -n mycc -v 0

peer chaincode instantiate -n mycc -v 0 -c ‘{“Args":[“init","a","100″,"b","200″]}’ -C myc

instantiate

peer chaincode invoke -n mycc -c ‘{“Args":[“invoke","a","b","10″]}’ -C myc

invoke

peer chaincode query -n mycc -c ‘{“Args":[“query","a"]}’ -C myc

query

程式更新

  • 版號更新為 ‘1.1’ (string, 每次異動都要不同)

CORE_PEER_ADDRESS=peer:7051 CORE_CHAINCODE_ID_NAME=mycc:1.1 ./chaincode_example02

跑完全部流程應該會看到這個

peer chaincode install -p chaincodedev/chaincode/chaincode_example02 -n mycc -v 1.1

peer chaincode upgrade -C myc -n mycc -v 4 -c ‘{“Args":[“init","a", “10″, “b","20″]}’

peer chaincode invoke -C myc -n mycc -c ‘{“Args":[“create","arick"]}’

peer chaincode query -n mycc -c ‘{“Args":[“query","arick"]}’ -C myc

參考資料

這陣子支援了一個案子評估 ossim 可行性, 其中 ossim-agent 負責解析 Log 字串並拆解成 ossim 統一格式, 原先以為處理得這麼即時是透過 linux 的 inotify 機制, 後來細看原始碼才發現其實沒這麼複雜, 就是

1. 開檔

2. 指標移到檔尾

3. 即時取得一行 Log

4. 沒有資料? 檢查 inode 是否異動(可能被 logrotate 給換檔)

4.1 inode 異動就重新執行步驟 1 和 2

4.2 休息一下

5. 重複 1-4

其實 tail -f 也是這麼做. 其實蠻多地方都可以用到這各技巧. 不一定非得用 inotify, 而且檔案頻繁異動時 inotify 是否效率比較好還有待評估..

Kotlin 練習: FileViewer

一個簡單的命令列檔案檢視器. 可以文字/十進位/十六進位顯示內容.

原始碼: FileViewer.kt

編譯

kotlinc FileViewer.kt -include-runtime -d FileViewer.jar

執行

java -jar FileViewer.jar -h FileViewer.kt

結果

檢查是否有

fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since;

另外, 如果有啟用 fastcgi cache, 記得將這兩個也列為 cache key, 如

fastcgi_cache_key “$scheme$request_method$host$request_uri$http_if_modified_since$http_if_none_match";

 

今天我就把 byte array 用 strncpy 複製…. 想說怎麼有時候會失敗. 萬惡的 \0 啊…

 

今天程式發生了一個小插曲, 本該正常的功能出錯了, 本以為是之前權限調整忘了同步異動, 可是權限正常. 後來仔細檢查發現居然是功能使用中的函數被刪掉… 對…被刪掉… 還蠻扯的. 真是什麼情況都會發生

還好有 Git, 本來想用 SmartGit | Blame 不過不好找, 後來發現有個簡單的方法

1. 將受害檔案的 commit 差異轉存檔案

* git log -p LossFunction.php > log.txt

2. 用文字編輯器查找消失的函數名稱, 就可以找到兇手了

 

MongoDB 適合大量讀寫?

純粹個人經驗, 可能有錯, 大量並發應用環境

1. Centos7 64bits

2. MongoDB 3.4 Enterprise (WiredTiger Engine, 有分片處理)

3. 儲存的資料有 log, cache, session

 

PHP Driver 預設長連接

  1. 大量並發, 如果 php-fpm 數量過多, 會導致 mgo 連線數不夠
  2. 長連接無法手動斷線或重連
  3. 手動重編改成短連接, 可解決 mgo 連線數問題, 但是會產生大量 TIME_WAIT 需要優化, 否則會發生 mgo 連不上的問題

 

MongoDB 的 upsert=true 可能會發生 duplicate key

  1.  這個問題太冏了. 只能自己處理

 

MongoDB 頻繁更新/讀取相同資料效能低落

  1. 使用 w=majority, journal=false, timeout=1s, 會發生  “waiting for replication timed out"
  2. 使用 w=1,journal=false,timeout=0 會發生"Operation timed out"
  3. session 不適合存 mongodb
    1. 更新頻繁, 寫入操作緩慢需要排隊, 操作逾時
    2. 可能發生 duplicate key