ページ

2010年12月14日火曜日

他のマシン上で起動しているTomcatをリモートからデバックする方法

他のマシン上で起動しているTomcatをリモートからデバックする方法

■ デバッグされる側の準備

・Tomcat 起動時に引数を指定する方法
$TOMCAT_HOME/bin/catalina.sh jpda start

・VM オプションを環境変数に設定する方法
(当方ではjsvcを利用してtomcatをデーモン化している為、
こちらを利用した。)

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005


■ 接続確認
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5005


■ ローカルのEclipseからリモートのTomcatをデバックする。

メニューバーから「実行(R)」→「デバッグ(B)」→「起動構成」
以下のように設定します。
・接続方法:ソケット
・ホスト名:接続するIPアドレス(または、ホスト名)
・ポート番号:5005 (-Xrunjdwpのaddressで指定したもの)


2010年12月8日水曜日

JMX経由でTomcatサーバを監視する

JMX経由でTomcatサーバを監視する

■ 概要
jconsoleで Windows PC から Linux サーバ上で稼動している Tomcat サーバに対して接続し、
リソース使用状態を監視する方法についてまとめた。

このjconsole、「接続しようとしても接続できない」という問題に結構出会う。

jconsoleとは
Sun JDK 6 の中には、コンパイラ javac の他にも、いくつか役に立つツールが含まれている。
jconsole は、Java プログラムに対し、次のような情報を得ることができる。

・パフォーマンス情報
・メモリの使用状態
・稼働中のスレッドに関する情報
・JMX


■ 設定方法に関する注意点

1.hostname -i を実行して、127.0.0.1 が返ってきた場合、まずこれを解決する必要がある。

------------------------------------------
# hostname -i
127.0.0.1
------------------------------------------

/etc/hosts を修正する
127.0.0.1 が返ってくる場合、/etc/hosts を見ると、
おそらく次のように記述されていると思う。

------------------------------------------
# cat /etc/hosts
127.0.0.1 localhost dev.ise-web.com
------------------------------------------

これを、次のように修正する。dev.ise-web.com に対し、このホストのIPアドレスを記述する。

------------------------------------------
# cat /etc/hosts
127.0.0.1 localhost
192.168.11.6 dev.ise-web.com
------------------------------------------

再度、hostname -i を実行して確認し、ホストのIPアドレスが返ってきたらOK。

# hostname -i
192.168.11.6

ホストに複数のIPアドレスが設定されている場合は?
例えば1つのホストにローカルIPとグローバルIPのように2つが設定されているようなケースでは、
「管理用PCから接続するときの IPアドレス」が hostname -i で返ってこなければならない。
Javaサーバの起動スクリプトの修正
tomcat を起動するときの Java のパラメータに、次のオプションを追加する。

------------------------------------------
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=7900
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
------------------------------------------

設定後、tomcat を起動する。

# /etc/init.d/tomcat start

ファイアウォールに穴をあける
例えば、Java サーバに iptables でパケット・フィルタリングを実施している場合、
「管理PCから jmx ポートへのアクセスを許可」の設定を行う必要がある。

ここで注意しなければならないのが、この機能では次の2つのポートを空ける必要があること。

・com.sun.management.jmxremote.port で指定したポート (上記例では 7900)
・そのポート~65535

したがって、例えば管理PC 192.168.11.10 が tomcat サーバのホスト
192.168.11.6 に jconsole で接続する場合、 192.168.11.6 上の /etc/sysconfig/iptables に次のような記述を加える。

改行せず、1行につなげる
-A RH-Firewall-1-INPUT -m state --state NEW
-m tcp -p tcp -s 192.168.11.10 --dport 7900:65535 -j ACCEPT

これで準備完了!


2010年12月5日日曜日

Postfix 設定手順のまとめ(OP25B対策)

Postfix 設定手順のまとめ

最近の国内プロバイダがOP25B (Outbound Port 25 Blocking) を利用するようになって
以降、プロバイダ外部への25番ポートへの接続を禁止するようになっているケースが多い。
これは、プロバイダのsmtpサーバの利用を許可するが、
送信アドレスはプロバイダの自ドメインに限るというものです。

当方ではフリーのダイナミックDNSに登録しており、
自宅用のメールアドレスを利用して外部メール(Gmailなどに)に送信したいのですが、
プロバイダから指定されたアドレスと異なる為に、

connect to gmail-smtp-in.l.google.com[74.125.53.27]

というような送信エラーとなってしまいます。

そこで、利用しているプロバイダの自ドメインを踏み台にして
外部メールに送受信する方法をメモしておく事にします。


※環境
CentOS 5.3
Postfix

【送信側の設定】

今インストールされているMTAを確認する。
# alternatives --display mta

postfixnのインストール
# yum install -y postfix

postfixの設定
# vi /etc/postfix/main.cf

-----------------------------------
#ホスト名を設定する。
myhostname = ise-web.com
#外部からのメール受信を許可
inet_interfaces = all
#メールサーバのネットワーク
mynetworks = 192.168.11.0/24
#メールボックス形式をMaildir形式にする
home_mailbox = Maildir/
#メールサーバーソフト名の隠蔽化
smtpd_banner = $myhostname ESMTP unknown

#以下文末に追加
#受信メールサイズ制限
message_size_limit = 10485760

#OP25B対策
relayhost = <プロバイダのSMTPサーバー>:587

#SMTP-Auth設定
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/authinfo
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = login, plain
-----------------------------------

プロバイダのSMTPサーバーに接続する為の情報を設定する。
vi /etc/postfix/authinfo
-----------------------------------
<プロバイダのSMTPサーバー> <プロバイダのメールアカウント>:<プロバイダのメールパスワード>
-----------------------------------

# chmod 640 /etc/postfix/authinfo
# postmap /etc/postfix/authinfo
# /etc/rc.d/init.d/postfix reload

SMTP-Auth設定
# /etc/rc.d/init.d/saslauthd start
# chkconfig saslauthd on
# chkconfig --list saslauthd

sendmailの停止
# /etc/rc.d/init.d/sendmail stop

メールサーバの切替え
alternatives --config mta

postfix起動
# /etc/rc.d/init.d/postfix start
# chkconfig postfix on
# chkconfig --list postfix


"fatal: no SASL authentication mechanisms"と表示される場合は必要なライブラリが不足しているので下記をインストールする。
yum -y install cyrus*


【受信側の設定】

Dovecotのインストール
# yum install -y dovecot

Dovecot設定
# vi /etc/dovecot.conf

# 以下の記述を追記
protocols = imap imaps pop3 pop3s
mail_location = maildir:~/Maildir

Dovecot起動
# /etc/rc.d/init.d/dovecot start
# chkconfig dovecot on
# chkconfig --list dovecot

2010年10月10日日曜日

Web高速化テクニック

1.HTTPリクエストを減らす
~ js、css、imgなどのコンポーネントをダウンロードする数を減らす。

【使える技】
・イメージマップ
・CSSスプライト (おすすめ!!)
・インライン画像
・複数のスタイルシートを1つに纏める。
・複数のスクリプトファイルを1つに纏める。

2.CDN(コンテンツデリバリーネットワーク)を利用する
~ 複数の拠点にコンテンツを分散してキャッシュさせ、
地理的に近い位置にあるサーバーからコンテンツを取得させる。
実装的には、HTMLを返す際に、コンテンツのURLをCDN向けに変換する
などの対応が必要となる。

【CDNサービスの種類】
・Akamai
・Mirror Image
・SAVVIS
・Limelight

3.Expires ヘッダを設定する
~ クライアントに指定した時期が来るまでキャッシュしたコンポーネントを利用させる。
【対応方法】
Apacheの定義ファイルに以下を追加する。
----------------------------------------
# Expiresヘッダを設定して1ヶ月間コンポーネントをキャッシュさせる
<IfModule expires_module>
ExpiresActive On
<FilesMatch "\.(jpeg|gif|css|js|swf)$">
ExpiresDefault "access plus 1 month"
</FilesMatch>
</IfModule>
----------------------------------------

4.コンポーネントをgzipする
~ HTML、CSS、JSなどのコンポーネントを圧縮して返すことで、レスポンス速度を向上させる。
【対応方法】
Apacheの定義ファイルに以下を追加する。
----------------------------------------
# DEFLATEを利用して画像系のファイル以外は、gzipで圧縮してレスポンスを返す。
<IfModule deflate_module>

#DEFLATEを有効化
SetOutputFilter DEFLATE

#圧縮レベルを指定(低1~9高)
#値が大きくなるほど圧縮率は大きくなりますが、その分CPUの負荷が高くなります。
#運用状況に合わせて徐々に値を上げるようにしましょう。
DeflateCompressionLevel 5

#ブラウザがNetscape 4.xの場合はtext/htmlのみ圧縮
BrowserMatch ^Mozilla/4 gzip-only-text/html

#ブラウザがNetscape 4.06-4.08の場合は圧縮しない
BrowserMatch ^Mozilla/4\.0[678] no-gzip

#ブラウザがMSIEの場合は全て圧縮
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

#画像ファイルは圧縮しない
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

#圧縮未対応ブラウザへは圧縮ファイルを送信しない
Header append Vary User-Agent env=!dont-vary

#ログの取得
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i' deflate
CustomLog /var/log/httpd/deflate_log deflate
</IfModule>
----------------------------------------

5.スタイルシートは先頭に置く
~ スタイルシートの読み込みを出来るだけHTMLの先頭のほうに置くことでレンダリングの速度が向上する。
【注意事項】
・IEの場合に、他のレンダリングをブロックする為、@importの使用は避ける。

6.スクリプトは最後に置く
~ スクリプトファイルの読み込みを出来るだけHTMLの最後のほうに置くことで
レンダリングの速度が向上する。
【注意事項】
・HTMLの読み込みが終わると、コンポーネントは最大2つまで並列に
ダウンロードされる。
・スクリプトを一番上でロードすると、スクリプトよりも下のコンテンツは、
レンダリングが中断される。
・スクリプトを一番上でロードすると、スクリプトよりも下のコンポーネントは、
ダウンロードが中断される。

7.CSS expressionの使用を控える
~ CSS expression は、CSSプロパティを動的に設定する手法です。

8.JavascriptとCSSは外部ファイル化する
【インラインの場合】
・コンポーネントをダウンロードする数が減るため、外部ファイルよりも高速。
【外部ファイルの場合】
・ブラウザにロードされたファイルがキャッシュされる為、2回目以降は最速。

9.DNSルックアップを減らす
~ サーバー側で、KeepAliveを利用して1つの接続を使い回し、
複数のリクエストに応えられるようにする事でパフォーマンスを向上させる。
【対応方法】
Apacheの定義ファイルに以下を追加する。
----------------------------------------
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
----------------------------------------

10.javascriptを縮小化する
~ 外部ファイル内の改行やスペースを除去してファイルサイズを削減することで、
ダウンロードの速度を向上させる。
【縮小化ツール】
・JSMin
・DojoCompressor
・Google Closure Tools

11.リダイレクトを避ける
301 ・・・ 恒久的な移動
302 ・・・ 一時的な移動
【注意事項】
リダイレクトで上のレスポンスコードを返すと、ブラウザの「戻る」ボタンが
正しく機能されることが保障される。

12.スクリプトを重複させない
【注意事項】
・同じページにスクリプトを複数回インクルードすると、
ページのロードが遅くなる。
・IEでは、スクリプトがキャッシュ不能である場合や
ページがリロードされた場合に余分なHTTPリクエストが
が生成される。
・FirefoxでもIEでも、スクリプトは複数回評価される。

13.ETagの設定を変更する

14.Ajaxをキャッシュ可能にする

2010年9月28日火曜日

SVNで特定のファイルやディレクトリに対する履歴を完全に削除する方法

SVNで特定のファイルやディレクトリに対する履歴を完全に削除する方法。
つまりなかったことにする方法。

svnadmin dump /opt/svn/repos | svndumpfilter exclude 除外したいパス > dump.svn
rm -fr /opt/svn/repos/*
svnadmin create /opt/svn/repos/
svnadmin load /opt/svn/repos/ < dump.svn
Basic認証用のパスワードファイルの作成とユーザーの追加                      
cd /opt/svn/repos/conf/          
htpasswd -c -m mypasswd ユーザーID
HTTP接続用のディレクトリに権限を付与します。
chown -R apache.apache /opt/svn/repos
chmod -R 777 /opt/svn/repos/db
mkdir -p /opt/svn/repos/dav/activities.d
chmod -R 777 /opt/svn/repos/dav
apacheを再起動します。
/etc/init.d/httpd restart

2010年9月26日日曜日

git よく使うコマンド


■ 初期設定

・コミットログに追加される利用者の情報を設定する。
git config --global user.name "<ユーザーID>"
git config --global user.email "<メールアドレス>"
git config --global color.ui "auto"

・既存のリポジトリの複製を作る。
git clone <複製したいリポジトリのURL>


■ コミット・プッシュ・プル

・現在のワークツリーの状態を確認する。
git st

・ローカルのブランチにコミットする。
git add -A && git commit -m "コメント"

・コミットをリモートのブランチにプッシュする。
git push

・リモートの変更をローカルに取り込む
git pull



■ 元に戻す

・ワークツリーを HEAD の状態に戻す。
git reset --hard
git clean -fd

・ローカルブランチのコミットを取り消す
git revert <コミットID>

・リモートブランチのコミットを取り消す
git revert <コミットID>
git push

・リモートブランチのコミットを取り消して、別のリモートブランチにプッシュする
git co develop
git revert <コミットID>
git push
git co master
git cherry-pick <コミットID>
git push


■ ブランチ

・すべてのブランチを確認する。
git branch -a

・ローカルに新規ブランチを作成する。
git branch newbranch

・リモートに新規ブランチを作成する
git co -b develop origin/develop ← 作成元になるリモートブランチをチェックアウトする
(作成したブランチがチェックアウトされた状態となる)
git branch newbranch ← チェックアウトしたブランチから新規ブランチを作成する
git co newbranch
git push origin newbranch ← リモートにプッシュする
git fetch ← フェッチして、履歴を取得する
git co develop ← 作成したローカルブランチは、1のブランチを参照しているため、削除してリモートを参照し直す。
git branch -D newbranch
git co -b newbranch origin/newbranch

・ローカルのブランチを削除する
git branch -d newbranch

・ローカルが参照しているリモートブランチを削除する
git branch -r -d origin/newbranch

・リモートブランチを削除する
git push --delete origin newbranch


■ タグ

・すべてのタグを確認する。
git tag

・ローカルに新規タグを作成する。
git tag newtag

・リモートに新規タグを作成する
git co develop ← 対象のブランチをチェックアウトする
git tag newtag ← チェックアウトしたブランチから新規タグを作成する。
git push origin newtag ← リモートにプッシュする

・ローカルのタグを削除する。
git tag -d newtag

・リモートのタグを削除する。
git tag -d newtag
git push origin :newtag



■ マージ

・リモートに作成したブランチから、masterブランチにマージする。
git co master ← masterブランチをチェックアウトする
git merge origin/newbranch ← リモートのマージ元ブランチから、マージする。(fast forward)
(履歴を一本化したい場合は、以下でもOK)
git rebase origin/newbranch
git push ← プッシュする


■ コンフリクトとその解消
git status ← コンフリクトを起こしたファイルを確認する。
git add <ファイル名> ← コンフリクトを修正して、インデックスに追加する。



■ その他のTIPS
・直前のコミットのコメントを修正する
git commit --amend -m "コメント"

・Macの.DS_Storeファイルをignoreに設定する。
echo .DS_Store >> ~/.gitignore
git config --global core.excludesfile ~/.gitignore

・ファイルの1行1行がどのコミットで記録されたかを確認する。
git blame <ファイル名>

・コミット済みのファイルを、リポジトリから消して.gitignoreで除外する
git rm --cached foo.txt
echo 'foo.txt' >> .gitignore
git add .gitignore
git commit -m "コメント"


・ブランチを切り替える際に、既に変更があるとエラーになる為の対策
git stash ← 変更をいったん横に避けておく。
git stash pop ← 横に避けておいた変更を戻す。


・ブランチの作成/変更/マージ履歴を確認
git show-branch


・git では空のディレクトリをリポジトリに含めることはできない為の対策
mkdir empty_directory
touch empty_directory/.gitignore
git add empty_directory/.gitignore

・コミットの履歴の要約だけを確認する。
git log --pretty=short

・コミットごとの変更内容をunified-diffの形で見る
git log -p


・サーバーはsvnで、ローカルでのみgitを利用する
git svn clone <リポジトリのURL> -T trunk --username <ユーザーID> ← svnリポジトリからgitリポジトリを作る
git svn show-ignore >> .git/info/exclude ← svn:ignoreを引き継ぐ
git svn rebase ← svnリポジトリの最新の変更を取り込む。
git svn dcommit ← 変更をsvnにコミットする。

git svn dcommit --rmdir ← 空のディレクトリを削除する場合

git svn log ← svnの修正履歴を最終確認する。


2010年9月25日土曜日

SAStrutsで提供されているバリデーションの一覧

~ 必須チェック ~
・必須チェック
アノテーション → @Required
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ 相関チェック ~
・他のプロパティと関連したチェックを行う
アノテーション → @Validwhen
属性
test(必須) 条件を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
args メッセージの引数を @Argアノテーションの配列で指定する。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ 文字数チェック ~
・最小文字数チェック
アノテーション → @Minlength
属性
test(必須) 文字列長の最小値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、minlength属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・最大文字数チェック
アノテーション → @Maxlength
属性
maxlength(必須) 文字列長の最大値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、maxlength属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ バイト数チェック ~
・最小バイト数チェック
アノテーション → @Minbytelength
属性
minbytelength(必須) 最小バイト数を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、minbytelength属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・最大バイト数チェック
アノテーション → @Maxbytelength
属性
maxbytelength(必須) 最大バイト数を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、maxbytelength属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ 正規表現チェック ~
・正規表現チェック
アノテーション → @Mask
属性
mask(必須) 正規表現を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
args メッセージの引数を @Argアノテーションの配列で指定する。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ 範囲チェック ~
・数値がintの範囲内か否か
アノテーション → @IntRange
属性
min(必須) 最小値を指定する。
max(必須) 最大値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、min属性で指定した値。
arg2 メッセージの3番目の引数を指定する。デフォルトは、max属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・数値がlongの範囲内か否か
アノテーション → @LongRange
属性
min(必須) 最小値を指定する。
max(必須) 最大値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、min属性で指定した値。
arg2 メッセージの3番目の引数を指定する。デフォルトは、max属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・数値がfloatの範囲内か否か
アノテーション → @FloatRange
属性
min(必須) 最小値を指定する。
max(必須) 最大値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、min属性で指定した値。
arg2 メッセージの3番目の引数を指定する。デフォルトは、max属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・数値がdoubleの範囲内か否か
アノテーション → @DoubleRange
属性
min(必須) 最小値を指定する。
max(必須) 最大値を指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
arg1 メッセージの2番目の引数を指定する。デフォルトは、min属性で指定した値。
arg2 メッセージの3番目の引数を指定する。デフォルトは、max属性で指定した値。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

~ 型チェック ~
・byteに変換可能か否か
アノテーション → @ByteType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・shortに変換可能か否か
アノテーション → @ShortType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・integerに変換可能か否か
アノテーション → @IntegerType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・longに変換可能か否か
アノテーション → @LongType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・floatに変換可能か否か
アノテーション → @FloatType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・doubleに変換可能か否か
アノテーション → @DoubleType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・日付チェック
アノテーション → @DateType
属性
datePattern 日付のパターンを指定する。
datePatternStrict 厳密な日付のパターンを指定する。(yyyy/MM/dd)のように指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・クレジットカード形式かどうかチェック
アノテーション → @CreditCardType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・メールアドレス形式かどうかチェック
アノテーション → @EmailType
属性
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。

・URLの形式かどうかチェック
アノテーション → @UrlType
属性
allowallschemas すべてのスキームを許可するかどうかを指定する。デフォルトはfalse。
allow2slashes ダブルスラッシュ(//)を許可するかどうかを指定する。デフォルトは、false。
nofragments URLの分割(#を含める)を許可しないかどうかを指定する。デフォルトは、false。
schemas 許可するスキームを指定する。複数ある場合は、(カンマ)で区切って指定する。
msg エラーメッセージを指定する。
arg0 メッセージの最初の引数を指定する。デフォルトは、プロパティ名。
target 入力チェックを有効にするアクションの実行メソッドを指定する。


2010年9月14日火曜日

OAuth認証の仕組みについて

近年、マッシュアップと呼ばれる仕組みが流行しており、
既存のWebサービスが次々とつながり、新たなWebサービスが登場している。
しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。
そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthです。

■ OAuth認証(オーオース)
~ 自分のアカウントへのアクセスを、ID・パスワードを渡さずに
第三者のサービスから利用できるようにする仕組み。





【事前準備】
・Consumer登録
1.事前にProviderにConsumer登録をしておく。
2.登録すると、Consumer KeyとConsumer Secretが発行される。
3.Consumer KeyとConsumer Secretは、以降のOAuth認証で使用する。


【OAuth認証の流れ】
・ユーザは、ConsumerにOAuth認証を行うように指示する。
1.通常は、Consumerのページにあるログインボタンなどをクリック。

・Consumerは、Providerからリクエストトークンを取得する。
1.Consumerは、ProviderへHttp通信でリクエストトークンを要求する。
(その際に、事前に発行されているConsumer Keyと、Consumer Secret
の値をパラメータとして付与します。)
2.ProviderはHttpのレスポンスとしてリクエストトークンを返す。

・認証用URLへのリダイレクト・ユーザ承認
1.Consumerは、発行されたリクエストトークンをURLに付与して、
Providerの認証用URLへリダイレクトを行う。
2.リダイレクト先で、Providerがユーザに対して、
Consumerが要求しているOAuth認証によるAPI利用を許可するか選択します。
3.承認した場合は、Providerは(通常は)Consumer登録時に設定した
コールバックURLへリダイクレトする。

・アクセストークンの取得
1.コールバックURLへのリダイレクトで、Consumerはリクエストトークンを
もとにアクセストークン取得をHttp通信でProviderへ要求する。
2.アクセストークン取得要求は、Consumer Keyとリクエストトークンなどを
パラメータに付与して呼び出す。(通常はAuthorizationヘッダに設定)
3.アクセストークン取得要求のパラメータも、Consumer Secretで署名した
値を付与する。
4.Providerは、レスポンスとしてアクセストークンを返す。

・OAuthでのAPI呼び出し
1.実際のAPI呼び出しは、取得したアクセストークンをパラメータに
付与して呼び出す。
2.アクセストークンとConsumer Key、およびパラメータをConsumer Secretで
署名した値を、Authorizationヘッダに設定に設定してAPIを呼び出すことで、
OAuth認証を利用したAPI呼び出しができる。


GIT(分散型バージョン管理システム)の特徴

Git(ギット)とは、
~ ソースコードの分散型バージョン管理システム。
動作速度に重点が置かれており、分散されたレポジトリがローカルマシンに
置かれている為、ネットにつながっていなくてもソースをコミットできる。


■ 集中管理方式のバージョン管理システム
~ サーバ上にだけリポジトリを持ちます。




■ 分散管理方式のバージョン管理システム
~ サーバ上のリポジトリ以外にも各開発者がローカルリポジトリを持ちます。




【分散型のメリット】
・一時的作業の履歴管理が容易
~ 各開発者の作業は、ローカルリポジトリへコミットすることになる為、
中央リポジトリに影響を与えることなく各開発者が変更を管理できる。

・柔軟なワークフロー
~ リポジトリ構成を階層化し、各グループのリポジトリ上の変更をリーダーが確認して、
上位のリポジトリへプッシュするという使い方ができる為、
各開発者が勝手にマスターのリポジトリへコミットするのを避けることができる。

・パフォーマンスとスケーラビリティ
・オフラインによる開発
・障害に強い
・オープンソースの改編物の公開に最適
・SVNを集中リポジトリとして利用可能


【分散型のデメリット】
・管理が煩雑に
・ロックができない
・細かいアクセス制御ができない
・リポジトリ単位しか作業セットを取得できない
・Windows用のツールが成熟していない
・一般開発者向けのノウハウが十分に蓄積されていない
・利用経験があるエンジニアを集めにくい


分散型のバージョン管理システムでは、下記のような使い方が出来る。
※ また、中央リポジトリにSVNを利用する事ができる。



2010年8月15日日曜日

JSTL1.1 (JSP2.0) タグライブラリ

■ JSTL1.1 (JSP2.0) タグライブラリ 一覧

【Core】
・変数をセットする:<c:set>
・変数を削除する:<c:remove>
・変数を出力する:<c:out>
・単一の条件分岐:<c:if>
・複数の条件分岐:<c:choose><c:when><c:otherwise>
・繰り返し(ループ):<c:forEach>
・文字列を区切り文字で分割する:<c:forTokens>
・ファイルをインポートする:<c:import>
・指定したURLにリダイレクトする:<c:redirect>
・URLエンコードする:<c:url>
・例外処理の定義:<c:catch>
・パラメータを指定する:<c:param>

【il8n】
・数値データを指定フォーマットで出力する:<fmt:formatNumber>
・日付データを指定フォーマットで出力する:<fmt:formatDate>
・文字列を数値データに変換する:<fmt:parseNumber>
・文字列を日付データに変換する:<fmt:parseDate>
・リソースメッセージを取得する1:<fmt:setBundle><fmt:message>
・リソースメッセージを取得する2:<fmt:bundle><fmt:message>
・リクエストの文字エンコーディングをセットする:<fmt:requestEncording>
・ロケールをセットする:<fmt:setLocale>
・タイムゾーンを設定する1:<fmt:setTimeZone>
・タイムゾーンを設定する2:<fmt:timeZone>

【Function】
・指定の文字列が含まれているかチェックする1:( fn:contains )
・指定の文字列が含まれているかチェックする2:( fn:containsIgnoreCase )
・文字列の位置を取得する:( fn:indexOf )
・文字列の先頭が、指定の接頭辞かチェックする:( fn:startsWith )
・文字列の最後が、指定の接尾辞かチェックする:( fn:endsWith )
・文字列の前後の空白を削除する:( fn:trim )
・配列を指定の文字で連結する:( fn:join )
・文字列、コレクション、配列サイズを取得する:( fn:length )
・文字列を置換する:( fn:replace )
・文字列を指定の文字列で分割する:( fn:split )
・文字列の一部を取得する:( fn:substring )
・指定文字列の位置以降の文字列を取得する:( fn:substringAfter )
・指定文字列の位置以前の文字列を取得する:( fn:substringBefore )
・大文字→小文字変換:( fn:toLowerCase )
・小文字→大文字変換:( fn:toUpperCase )
・文字列内のXML特殊文字を変換する:( fn:escapeXml )

【XML】
・XML文書を解析する:<x:parse>
・指定したXPath式で取得した値を、出力する:<x:out>
・指定したXPath式で取得した値を、変数にセットする:<x:set>
・指定したXPath式で取得した値を、繰り返し処理する:<x:forEach>
・指定したXPath式で取得した値の、単一の条件分岐:<x:if>
・指定したXPath式で取得した値の、複数の条件分岐:<x:choose><x:when><x:otherwise>
・XML文書をXMLスタイルシートで変換する:<x:transform>

【Database】
・データベースへ接続する:<sql:setDataSource>
・データベースのレコードを取得する:<sql:query>
・データベースにレコードを登録/更新/削除する:<sql:update>
・トランザクションを定義する:<sql:transaction>
・パラメータを指定する:<sql:param>
・日付型のパラメータを指定する:<sql:dateParam>

2010年8月14日土曜日

JAVAの3層アーキテクチャについて

■ 3層アーキテクチャとは
~ クライアント/サーバー型のアプリケーションを3つの機能モジュールに分けて開発する手法の事。

【プレゼンテーション層】
~ ユーザインタフェースを提供するレイヤー
【ビジネスロジック層】
~ ユーザに提供するデータの加工処理を行うレイヤー
【データ層】
~ データベースへアクセスするためのレイヤー

■ 前提条件
業務ロジックを組み込むLogicクラスは、バッチなどの別アプリケーション
からも共用したい為、トランザクションは、LigicクラスにAOPで組み込む。


■ Struts・Spring・ibatisを使ったクラス構成



■ SAStruts・S2Contener・S2JDBCを使ったクラス構成



※ オブジェクトの依存とは
Javaでは、各オブジェクトは「他のオブジェクトに依存しない独立した存在であるべき」
といわれます。
この依存性とは、「あるオブジェクトをインスタンス化する為には、
他のオブジェクトもインスタンス化しなければいけない」という状況(参照依存)
を指しており、依存関係にあるオブジェクトは、利用性が下がってしまいます。

よく「1箇所を修正したら、他の箇所も修正しなければいけなくなる」という
ソースの影響範囲のことを依存性だと勘違いされる事が多いのです。。。

2010年8月10日火曜日

JSP2.0 EL式

JSP2.0よりEL式が導入されました。
EL式は式言語とも呼ばれ、演算結果や値の参照の結果を出力するために使用されます。

EL式は

${式}

というような形で記述し、「{}」で囲まれた式を計算し、計算結果を出力します。

【演算子の使用例】

●算術演算子

5×2 : ${5*2}

●比較演算子

3>5 : ${3>5}

●論理演算子

3と5の比較を否定 : ${!(3==5)}

●2項演算子

3>2の場合は100、それ以外は200 : ${3>2?100:200}

●empty

<% String data=""; %>
変数「data」が空かどうか : ${empty data}

2010年8月5日木曜日

iPhoneの隠しコマンド

電話番号の記入画面で特定の記号と番号を入力すると、
さまざまな機能を使用したり確認する事ができる。

しかもこの隠しコマンドは「隠しコマンド」と呼ばれるだけあって、
アップル社は公式に公表していない。

*#06# ……『IMEIナンバー』という固有の番号を表示する事ができる
*#21# ……『iPhone』のさまざまな機能の設定状態をチェックできる
*#30# …… 自分の番号通知設定を表示することができる
*#33# …… 通信規制の状態をチェックすることができる
*#61# …… 各種データ転送や非同期データサーキット等の状態をチェックできる
*#62# …… 応答不可能の際にどのような設定になっているのかをチェックできる
*#76# …… SettingIntegrationFaild接続ラインのチェックができる

参考URL
http://rocketnews24.com/?p=42212

2010年7月30日金曜日

よく使うシェルコマンドの纏め

ファイルのコピー
cp コピー元ファイルパス コピー先ファイルパス

フォルダのリネーム
mv -v 変更前フォルダパス 変更後フォルダパス

ディレクトリごとファイルを削除する。
rm -Rf ディレクトリのパス

シェルの実行結果をログファイルに出力する。
実行したいシェル.sh  2>&1 | tee ログファイル名

SVNの指定したりビジョンを比較して結果をファイルに出力したい場合
svn diff svn+ssh://192.168.11.5/opt/svn/repo/kablog/branches/B090210 -r 28261:28260 > diff.txt

cronのジョブ一覧を確認する。
ll /etc/cron.d
crontab -l

マウントの情報を確認する。
view /etc/fstab

ZIPファイルを解凍する。
unzip -o zipファイル名 -d 解凍先ディレクトリ

ファイルの転送
scp -rp 転送元ファイル サーバーIP:転送先ディレクトリ

コマンドの実行履歴を表示する
history

ターゲットシステム上で計測された HotSpot Java 仮想マシン (JVM) を一覧表示する。
jps

ログ出力を監視する。
tail -f ログファイル名

rootユーザーでログインしたユーザーのIPアドレスを調べる
less /var/log/secure | grep root

ファイルを閲覧する。
less ファイル
q で終了。/ で検索。fで1ページ進む。bで1ページ戻る。

シンボリックリンクを作成する。
ln -s リンク先 リンク元

ディスクの空き容量を確認する。
df

指定したディレクトリの空き容量を各ディレクトリ毎に表示する。
du -sh ディレクトリのパス/*/

指定したディレクトリのファイル数を確認する。
ls -lR ./ | wc -l
find ./ | wc -l

ファイルだけ削除する。
find ./ -type f | xargs rm

指定したディレクトリのiノードサイズを調べる。
df -i /mnt/nas

指定したホスト名のドメイン情報を探索する。
dig ホスト名

自分から別のホストまでのネットワーク経路について表示する。
traceroute ホスト

apacheの設定ファイルの書式をチェックする。
/etc/init.d/httpd configtest

apacheを再起動せずに設定ファイルの変更を反映する。
/etc/init.d/httpd reload

WARファイルの所有者をTOMCATユーザーに変更する。
chown tomcat:tomcat /mnt/nas/deploy/app/kablog.war

WARファイルのパーミッションを変更する。
chmod 755 /mnt/nas/deploy/app/kablog.war

踏み台にして別サーバーにログインする。
ssh root@192.168.11.XXX

プロセスID 12829のJVMのGC統計データを3秒毎に表示する。
jstat -gcutil -t 12829 3000 2>&1 | tee ./gc.log

シェルをバックグラウンドで実行する。
nohup ./sample.sh &

バックグラウンドで実行しているシェルの一覧を表示する。
jobs

バックグラウンドプロセスをフォアグラウンドで実行する。
fg %ジョブID


フォアグラウンドプロセスをバックグラウンドで再開する。
bg %ジョブID

仮想スクリーンを新しく開く
screen

仮想スクリーンの一覧を表示する
screen -list

仮想スクリーンに戻る。
screen -x

トンネル経由でリモートに接続する。
ssh -L <ローカルポート>:<接続ホスト>:<接続ポート> <ユーザーID>@<経由するホスト>

トンネル経由でリモートに接続する。(SSH2)
ssh -2 -i <秘密鍵> <ユーザーID>@<経由するホスト> -L <ローカルポート>:<接続ホスト>:<接続ポート>

用語集・ツール名称のまとめ

■ 用語

RSS
~ Webサイトの更新情報を、見出しや要約などをまとめた形式で配信するための技術のこと。
更新されたWebページのタイトルやURL(リンク)、概要、更新時刻といった、
更新されたWebページに関する情報(メタデータ)を記述することができる。

Atom(エイトム)
~ Webサイトの見出しや要約などのメタデータを構造化して記述するXMLベースのフォーマット。
主にサイトの更新情報を公開するのに使われている。

ワードランク
~ Webサイト内で頻繁に使用されている単語のランキング。
ワードランクの高い単語がそのWebページ内で重要視され、検索エンジンにヒットしやすくる。

IDF
~ 文章中の重要とみなされる単語を抽出するためのアルゴリズムの事。

RDF
~ 情報についての情報(メタデータ)の表現方法についての枠組み。
RDFで記述される情報は書籍における図書カタログのようなもので、
コンピュータが扱う情報の分類や検索などの自動化・効率化を図ることができる。

トラックバック
~ ウェブログ(ブログ)の機能の一つで、別のウェブログへリンクを張った際に、
リンク先の相手に対してリンクを張ったことを通知する仕組みのこと。

エントリー
~ ウェブログの1つ1つの文章のまとまりのこと。
コンテンツデータ1件単位のことで通常は1ページ分の記事データを意味しています。

タグクラウド
~ Webサイト上で各項目にメタデータとしてつけられたタグを、一挙に集めて視覚的に表示すること。
同じタグが与えられた多さによって、フォントサイズを変えて表示される。
そのため、文字の大小によって一目で(あるいは「視覚的に」)タグの人気がわかるようになっている。

CAPTCHA(キャプチャ)
~ 文字を歪ませた画像をユーザに提示し、そこに書かれた文字列を入力させることで、相手が人間であるということを確認する手法

ブログロール
~ 他ブログへのお気に入りリンクリストのこと。

ブロゴスフィア
~ ブログおよびブロガーによって形成されるコミュニティのこと。
ブログ圏とも呼ばれる。

ログファイルのローテート
~ ログファイルが蓄積されて、巨大化されるのを防ぐために、古いファイルを回転させて、
バックアップを保持しながら効率的に古いログを削除していく仕組み。

NAS
~ LAN経由でアクセスできるファイルサーバー専用のハードディスクの事。

POJO(ポジョ)
~ Plan Old Java Objectの略で、シンプルで、依存性をなくしたオブジェクトの事。PrintStreamのwriterでレスポンスを返す処理など。

OpenSearch
~ 複数の検索サイトにクエリーを投げて、その結果を合成・加工して表示するといった事が可能になる仕組みの事。

MTA
~ ユーザーが送信したメールを受け取って、他のサーバーと連携する機能

Oracle RAC(Real Application Clusters)
~ 1つのデータベースを複数のサーバーで共有する仕組みの事。クラスタ化した複数のAPサーバーから1つのDBを共有させるための仕組み。

サニタイズ
~ 入力されたデータの危険な部分を無力化する操作のこと。

cron(クーロン)
~ Unixにおいて、定期的にコマンドを実行するためのデーモンの事。

UTM
~ ファイアウォールとVPN機能をベースに、アンチウイルス、不正侵入防御、Webコンテンツフィルタリングといった複数のセキュリティ機能を統合的に管理する事。

サイトジャック
~ サイト(ホームページ) を乗っ取ること。ウィルスをしこんで、訪問者にトロイなどをしかけて、ポッドネットを広げるのに使います。

フェイルオーバー
~ サーバに障害が発生した場合に、代替サーバが処理やデータを引き継ぐ機能

マルチキャスト
~ コンピュータネットワークにおいて、決められた複数のネットワーク端末(ノード)に対して、同時にパケット(データ)を送信する事。

Webサービス
~ SOAPやRESTなどの技術を用いてメッセージの送受信を行う技術、またはそれを適用したサービス。

WSDL
~ Webサービス記述言語、またはそれによって記述された定義ファイルの総称。XML形式で表記される。

SOAP(ソープ)
~ XML形式のプロトコルを用いメッセージの送受信を行うWebサービス。XMLをリクエストしてXMLがレスポンスになる。

REST(レスト)
~ GETメソッドのURLクエリー部分やPOSTメソッドのボディ部に、「引数名=値&引数名=値…」という形式で引数を渡し、XML形式のレスポンスが返ってくるWebサービス。
Ajaxリクエストの戻り値として利用される事が多い。

ステートレス
~ クライアントとなるネットワークアプリケーションが、サーバーに処理を依頼する際に、処理を行う単位でソケット接続をし切断をすること。
クライアントが処理単位で切断するため、サーバー側はクライアントを特定できず、処理をまたいで情報を保存することができない。

ステートフル
~ クライアントがひととおりの処理が終わるまでセッションを切断しない方法。

スケーラビリティ
~ コンピュータシステムの持つ拡張性。システムの利用者や負荷の増大に応じて、柔軟に性能や機能を向上させられることを意味する。

JCP
~ Javaプラットフォームの将来のバージョンや機能に関与する定義に関与することを許した標準化プロセス。

JAX-RS(JSR 311)
~ JavaプラットフォームにおいてREST(REpresentational State Transfer)スタイルのWebアプリケーションを開発するためのAPI仕様。

JSON(ジェイソン)
~ 構造化されたデータを記述するための,テキスト・ベースのデータ記述言語の一つ。
JavaScript(ECMAScript)でオブジェクト・リテラルを記述する構文をそのまま使っている。

マイルストーン
~ 必要に応じて適宜工程の修正を行って新たな計画を立て再び実施を行うという方法でプロジェクトを進めてゆく方法。


■ツール・API関連の名称

ATLASSIAN JIRA(ジラ)
~ バグや課題などを管理してトラッキングを行うためのWEBツール

OpenSymphony Quartz(クオーツ)
~ ジョブスケジュール管理ツール。バッチ処理のジョブスケジューリングを行うためのJavaのAPI

Apache James(ジェイムス)
~ MTAが実現可能な電子メールアプリケーションサーバ
Matcher-特定のメールアドレスパターンの時だけ実行したりできるAPI
Mailet-到着したメールをトリガーにしてプログラムを呼び出すAPI

Apache Lucene(ルシーン)
~ 大量のデータから指定したキーワードを探し出すためのJavaのAPI

Apache iBATIS(アイバティス)
~ SQLクエリを POJO (Plain Old Java Object) にマッピングする永続性フレームワーク

Sen(セン)
~ 入力文を形態素(言語で意味を持つ最小単位)に分解し品詞を付与するJavaのAPI

ipadic(アイパディック)
~ 形態素解析を行う際に利用される辞書。

JMagick
~ JavaからImageMagick(イメージファイルを加工するツール)を扱う為のJavaのAPI。gifファイルのリサイズなどを行う。

Apache Velocity(ベロシティ)
~ Javaベースのテンプレートエンジン。メール送信の際の定型文などに利用される。

java.net ROME
~ JavaでAtomやRSSフィードを取得する為のAPI

Citrix NetScaler(ネットスケーラー)
~ Google,Yahoo!,amazon,mixiが選んだロードバランサー
高性能なロードバランサー機能、Webサーバの性能を引き出すアクセラレーション機能、SSL-VPNやDDoS防御、
SQLインジェクション対策など高度なセキュリティ機能を持った次世代ロードバランサー

Apache Maven(メイブン)
~ プロジェクトのビルド、テスト、ドキュメンテーション、成果物の配備など、プロジェクトのライフサイクル全体を管理する
ソフトウェアプロジェクト管理ツール。サーバ環境のデプロイに使用される。

Xen(ゼン)
~ 一つのハードウェアで複数のオペレーティングシステム (OS) を並列実行・制御するソフトウェア。

アッズーリ Clay(クレイ)
~ データベース開発支援をおこなうeclipse用プラグイン。
Eclipse上でグラフィカルに各種データベースの設計が行え、その設計情報を元にテーブルを作成するSQLスクリプトを生成できる。

Openssl
~ SSLを実現できる。

Hudson(ハドソン)
~ MavenやAntなどで記述されたビルドプロセスを定期的に実行し、結果をモニタリングするもの。

Duplicity(デュプリシティ)
~ 暗号化された tarフォーマットのボリュームを作成し、それらをリモート又はローカルのファイルサーバにアップロードすることにより、ディレクトリをバックアップする。

OpenSymphony OSCache
~ J2EEのキャッシングフレームワーク。動的コンテンツの生成結果をメモリにキャッシュ(一定期間保存)し、
その間に受けたリクエストに対してはキャッシュの値を返すことにより、生成の処理数を減らす。

Jetty
~ Javaで書かれたHTTP/アプリケーションサーバおよびサーブレットコンテナ技術。
シンプルさ、拡張性、柔軟性などを特徴とし、リッチメディアや組み込みアプリケーション向けに使われている。

Ruby
~ オブジェクト指向スクリプト言語であり、従来Perlなどのスクリプト言語が用いられてきた領域でのオブジェクト指向プログラミングを実現する。

Rails
~ Rubyで書かれているオープンソースのWebアプリケーションフレームワーク。

Urchin(アーチン)
~ Webサーバのアクセスログを利用してホームページへの訪問者を多角的に解析する高機能アクセス解析ツール。

SAStruts
~ Strutsフレームワークに、Seasar2流の楽に作れるエッセンスを統合したjavaフレームワーク。

Restlet
~ REST通信を行うアプリケーションを構築するJavaフレームワーク。

RESTEasy
~ REST通信を行うアプリケーションを構築するJavaフレームワーク。JBoss系。

Jersey
~ REST通信を行うアプリケーションを構築するJavaフレームワーク。GlassFish(SUN)系。

CDN(コンテンツデリバリネットワーク)
~ ネットワーク上にキャッシュやミラーと呼ばれる機器を複数配置してネットワークやサーバにかかる負荷を分散化し、高速なコンテンツ配信を可能とする技術。
ライムライトなどが有名。

Git(ギット)
~ ソースコードの分散型バージョン管理システム。動作速度に重点が置かれており、分散されたレポジトリがローカルマシンに置かれている為、ネットにつながっていなくてもソースをコミットできる。

2010年7月25日日曜日

MSN メッセンジャー の隠し絵文字

■ MSN隠し絵文字の一覧

隠し絵文字
レインボー(r) または (R)
太陽(#)
ASL(?)
手錠(%)
その他の絵文字
(a) または (A)
ビール(b) または (B)
コーヒー(c) または (C)
ドリンク(d) または (D)
手紙(e) または (E)
(f) または (F)
ギフト(g) または (G)
サングラス(h) または (H)
電球(i) または (I)
(k) または (K)
ハート(l) または (L)
二人(m) または (M)
下に親指(n) または (N)
時計(o) または (O)
カメラ(p) または (P)
(S)
電話(t) または (T)
ハートブレイク(u) または (U)
萎れた花(w) または (W)
人1(x) または (X)
上に親指(y) または (Y)
人2(z) または (Z)
(&)
テープ(~)
ネコ(@)
ケーキ(~)
右にならえ({)
左にならえ(})
(*)
みゆ(6)
音符(8)
赤面:$
ムー:( または :<
ニコ:)
ありり:|
コラー:@
コウモリ:{
ニヒ:>
ホー:o
ペロっ:p
ムニャムニャ:s


こんな感じで入力すると、
隠し絵文字が表示される。

({) http://www.ise-web.com (})



2010年7月17日土曜日

Apache プロジェクトの一覧

HTTP Server ~ 言わずと知れたWebサーバー
Abdera ~ JavaでAtom(サイトの更新情報等などを受け持つXML文書の仕様)を取り扱うAPI。
ActiveMQ ~ メッセージキューイング(処理命令をキューに送信して、順に処理させる。)
Ant ~ ビルドツール。JavaのビルドやJavadocの生成。SCPやJUnitなども実行できる。
APR ~ Apache HTTP Server のサポートライブラリ。OSとソフトウェアの間で環境の違いを吸収する。
Archiva ~ ビルド成果物のリポジトリマネージャ。
Avro ~ データ交換のフレームワークで、サーバ間でのデータのやりとりなどに利用される。
Buildr ~ RubyベースのJavaアプリ用ビルドシステム
Camel
Cassandra ~ key-valueストア型のNoSQLデータベース。
Cayenne ~ O/Rマッピングフレームワーク。
Click
Cocoon
Commons
Continuum
CouchDB
CXF
DB
Directory
Excalibur
Felix
Forrest
Geronimo
Gump
Hadoop ~ 大量のデータを手軽に複数のマシンに分散して処理できる
Harmony
HBase
HttpComponents
Jackrabbit
Jakarta
James ~ メールサーバー。メールの受信をトリガーにしてJavaを実行できる。
Lenya
Logging ~ log4jなどの、ログ出力管理に利用される。
Lucene ~ Javaで記述された全文検索ソフトウェア。大量のデータから、指定したキーワードを探し出す。
Mahout
Maven ~ Ant(build.xml)に代わるビルドツール。コマンドラインに記述するだけで一度に実現できる。
Mina
MyFaces
Nutch
ODE
OFBiz
OpenEJB
OpenJPA
OpenWebBeans
PDFBox
Perl
Pivot
POI ~ WordやExcelといったMicrosoft Office形式のファイルを読み書きできる。
Portals
Qpid
Roller
Santuario
ServiceMix
Shindig
Sling
SpamAssassin
STDCXX
Struts ~ Webアプリケーションを開発する際に利用されるフレームワーク
Subversion ~ バージョン管理
Synapse
Tapestry
Tika
TCL
Tiles ~ HTMLのヘッター部、ボディー部などのレイアウトを再利用したり一元管理できる。
Tomcat ~ 言わずと知れたJavaのWebアプリケーションサーバー
TrafficServer
Turbine
Tuscany
UIMA
Velocity ~ Javaのテンプレートエンジン。XMLやメール文などのに利用される。
Wicket
Web Services
Xalan
Xerces
XML
XMLBeans
XML Graphics

2010年7月9日金曜日

2010年6月29日 Tomcat7 ベータ版 リリース

先日、Servlet3.0に対応した、Tomcat7のベータ版がリリースされました。
Servlet-APIの仕様は、フレームワークなどの今後の動向に大きく影響するため、
Servlet 3.0 の新機能について纏めてみました。


■ Servlet 3.0 の新機能

・XML設定のアノテーション化
~ Java SE 5 から利用可能になったアノテーションを利用して、
今まで web.xml に記載していた Servlet や Filter 等の設定を
アノテーションで記載できるようになった。

・web.xmlの分散化
~ 外部のフレームワークやライブラリの設定を web.xml 以外の
ファイル (web-fragment.xml) に記載できるようになったため、
web.xml の肥大化を抑制でき、またフレームワークの設定管理
が容易になっています。

・マルチパート対応
~ Servlet API だけでファイルをアップロードすることができる。

・非同期処理の実現
~ この非同期処理機能は、Comet/Reverse Ajax 等のアプリケーション
を実装できる他、DB アクセス等とても処理に時間がかかるような処理を
非同期で処理する事ができるようになります。

例えば、HttpServlet のスレッドとは別のスレッドで非同期に実現する事で
DB が高負荷時に HttpServlet の最大スレッド数に到達し
Web のアクセスが不可になる状態を防ぐ事もできます。
その他では、HttpServletRequest に login/logout/authenticate のメソッドが含まれ、
プログラムを利用しログイン/ログアウト処理を実装できるようになった他、
@ServletSecurity を使用して web.xml に記載していた < security-constraint > の設定を
プログラム中で宣言できるようになっています。

2010年6月28日月曜日

JGroupsを利用したクラスタ関連 ~その四 マージの仕組み ~

パーティションの結合(MERGE2)
~ MERGEは、通信障害によって分裂した複数のマルチキャストグループを
1つに結合する仕組みです。
FDやFD_SOCKにより障害検知されたメンバーはグループから除外される事に
なりますが、再度、通信可能な状態となると、本処理により再びグループに
参加することが出来ます。
ここでは、コーディネーターAからみた視点で記述しています。

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRDFTtHsIRolLtxFuvQq67qs5r7IERnDpGmrj1-TQTMFEV4zhfdDUAKZd5-GStRQ5L1L7KUEBItxZ_XS3D1WEO3OPwYkbe0Z38Oosr6RlexPEH7QE1OSLtz92PI0d45c88DT0Hevguri8/s1600/jgroups_merge_image1.JPG

コーディネーターであるメンバーAが通信不能となった場合、
マルチキャストグループは2つのパーティション([A],[B,C])
に分割されます。

この場合、メンバーAとメンバーBがコーディネーターとなり、
各パーティションのコーディネーターとなります。

この状態において、再度、通信可能な状態になると、
2つに分裂していたパーティションが1つになる為、
1つのパーティション内に2つのコーディネーターが
存在する事になります。

コーディネーターは、定期的にGET_MBRS_REQを送信して、
現在のコーディネーターを調査し、コーディネーターが
自分だけであるという事を確認しています。

GET_MBRS_RSPメッセージによって、自分以外のコーディネーターが
他に存在していると知ると、2つのコーディネーターを結合する為の
マージ処理が行われます。

この場合、メンバーAとBの2つのコーディネーターが存在する事になり、
マージリーダー(※1)に対してもうひとりのコーディネーターが
結合される事になります。

----------------------------------------------------------------
※1.マージリーダーとは
2つのコーディネーターが存在していた場合、「IPアドレス:ポート」
を昇順にソートした時の先頭になるコーディネーターが、マージリーダーとなり、
マージリーダー以外のコーディネーターは、マージリーダーのメンバーとなります。
----------------------------------------------------------------

マージリーダー(コーディネーターA)は、コーディネーターBに対して
MERGE_REQメッセージを送信します。
MERGE_REQメッセージを受信したコーディネーターBは、
自分のもっているメンバーリストをMERGE_RSPメッセージとしてメンバーAに
返信します。

メンバーリストを受信したメンバーAは、自分のメンバーリストとメンバーCが
持っていたメンバーリストを結合し、最新のメンバーリストを作成後、
すべてのメンバーに対してVIEWを送信します。

JGroupsを利用したクラスタ関連 ~その参 障害検知の仕組み ~

障害検知(FD)
~ FD(FailureDetection)は、ハートビートメッセージを利用して、
障害が発生したメンバーを検出する為の仕組みです。
メンバーは、HEARTBEATを受信すると、HEARTBEAT ACKを返信する事で
これに応答し、正常に疎通出来ることを定期的に確認しています。
各メンバーは、A→B→C→Aのようにリング状に、メンバーリストにいる
自分の次のメンバーに対して監視するようになっています。
ここでは、メンバーAからの視点で記述しています。

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRDFTtHsIRolLtxFuvQq67qs5r7IERnDpGmrj1-TQTMFEV4zhfdDUAKZd5-GStRQ5L1L7KUEBItxZ_XS3D1WEO3OPwYkbe0Z38Oosr6RlexPEH7QE1OSLtz92PI0d45c88DT0Hevguri8/s1600/jgroups_fd_image1.JPG

メンバーAは、メンバーBに対して定期的にHEARTBEATメッセージを送信し、
メンバーBがこれに応答する HEARTBEAT ACKメッセージを返信する事で、
通信状態を確認しています。
同様に、メンバーBはメンバーCの障害を監視しており、メンバーCは
メンバーAの障害を監視しています。

メンバーBが通信不能な状態になると、メンバーBに対してHEARTBEATを
送信していたメンバーAは、一定時間以上、メンバーBからの応答がない為、
メンバーAの障害を検出します。(FDによる障害検知)

但し、この時点では障害が発生しているかもしれない(容疑者)の状況であり、
他メンバーから再確認させるの為の検証フェーズが開始されます。

メンバーAは、メンバーBの障害を検出した事を他メンバーに知らせる為に、
SUSPECTメッセージをマルチキャストで送信します。

メンバーA、メンバーCは、SUSPECTメッセージを受信し、メンバーBに障害が
検出された事を知る為、検証フェーズ(※1)が開始されます。

----------------------------------------------------------------
※1.VERIFY_SUSPECT
障害を検出した場合、本当にそのメンバーが通信不可能である事を
再確認する為に、「ARE YOU DEAD」メッセージによる再検証が行われます。
また、この検証する仕組みの事は「VERIFY_SUSPECT」と呼ばれ、
SUSPECTメッセージを受信すると開始されます。
「ARE YOU DEAD」メッセージの送信に対する「I AM NOT DEAD」
メッセージの応答によって障害を判定しています。
----------------------------------------------------------------

メンバーB、メンバーCは、メンバーAに対して、「ARE YOU DEAD」メッセージ
を送信後、「I AM NOT DEAD」メッセージの応答を待ちます。
この応答が一定時間返ってこない場合、メンバーAは障害が発生したと
判定されます。

また、メンバーAは、これまで監視していたメンバーBがいなくなった為、
自分の次のメンバーにあたるメンバーCの障害監視を始める事になります。

このようにFDは、ハートビートを送信する事で、相手の通信状態を確認する
為の仕組みを担っています。

----------------------------------------------------------------
※ポイント
障害監視していた自分の隣のメンバーが除外された場合、次は、
その隣のメンバーに対して障害監視を始めることになります。
----------------------------------------------------------------

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjo5W-nifhDa4u4XVnBAGqhVh9vAel2CWAtb_HXdWVY5i2haCfbfejvFTx7wE8BxPiBKctTiqiIz6ftkmI8W4HrKdrc0IX4CexJ11xHCX_2o4cpBJ-WpdMxlWDavOGLw_9GtrhSxH4AcKE/s1600/jgroups_fd_heartbeat.JPG

障害検知(FD_SOCK)
~ FD_SOCKは、自分自身の障害を検知して、いつまでもメッセージを
送り続けないようにする仕組みです。
KEEP_ALIVE(トラフィックを2時間受信していないソケットにハートビート
を送信する)で、メンバーリストの隣のメンバーにソケット接続し、
LANを切断するなどしてコネクションが切断された場合に、障害を検出します。
また、FD_SOCKは、コネクションを閉じずにホスト (またはスイッチや
ルーター)がクラッシュすると、KEEP_ALIVEによるハートビートが送信される
2 時間後まで検出する事が出来ません。

各メンバーは、A→B→C→Aのようにリング状に、メンバーリストにいる自分
の次のメンバーに対して監視するようになっています。
ここでは、FDの処理と比較する為、メンバーBからの視点で記述しています。

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPwBu1zt9KFpTh_izEqHeaF9tuNxDdu1n5mWPTprxzrtxAFiFGhdMM0QIM4jDdpD8gKqvqIpupthgpetli-x-V9sultN6uxVyERfE1sRIpqRJN1U42YPlUMerXQw5JUKtdmMfPpDIuTy4/s1600/jgroups_fd_sock_image1.JPG

メンバーBは、自分の次のメンバーにあたるメンバーCに対して監視(ソケット接続)
しています。
(VIEWメッセージの受信によりメンバーリストが更新されると、
その度に接続しなおしています。)

メンバーBのLANが切断されると、そのタイミングでコネクションが閉じられ、
メンバーCの障害を検出します。
また、次のメンバーAに接続しようとしますが、接続できない為、
メンバーAの障害も検出します。

これにより、メンバーBは、メンバーAとメンバーCを自分のメンバーリストから除外して、
いつまでもメッセージを送信し続けないようにしています。

FDとFD_SOCKの関連性
FDは、他メンバーの障害を検出するのに対し、
FD_SOCKは、自分の障害はすぐに検出できますが、他メンバーの障害は、
KEEP_ALIVEが行われる最大2時間後まで検出する事が出来ません。
(上記の例の場合、メンバーBのLANを切断してもメンバーAはFD_SOCK
だけでは即座に検知する事が出来ない)
FDとFD_SOCKを組み合わせる事により、安定した障害検出を行うことが
出来るようになります。

----------------------------------------------------------------
※ FDとFD_SOCKの特性
FD
・過負荷の状態にあるマシンは、are-you-alive 応答の送信時に
パフォーマンスが低下する恐れがある。
・メンバーは、デバッガ/プロファイラでサスペンドしたときでも疑われてしまう。
・タイムアウトを小さくすると、間違った疑いの可能性が大きくなり、
ネットワークトラフィックが増大する。
・タイムアウトが大きいと、クラッシュされたメンバが一定の時間検出されず、
破棄されない。
FD_SOCK
・デバッガでサスペンドしてもTCP接続はまだオープンなので問題がない。
・同様の理由により、高負荷の状況でも問題とはならない。
・メンバーのTCP接続が中断された場合にのみ疑われ、
ハングしたメンバ検出されない。
・スイッチがクラッシュした場合は、TCPタイムアウトになるまで検出されない。
----------------------------------------------------------------

JGroupsを利用したクラスタ関連 ~その弐 参加・離脱の仕組み ~

参加(JOIN)
~ 参加(JOIN)とは、JGroupsリスナーの起動時に行われる
マルチキャストグループに加わる為の仕組みの事です。

・他メンバーが存在しない状態でリスナーを起動した場合



メンバーAは、グループ内に存在するコーディネーター(※1)を
見つける為に、GET_MBRS_REQメッセージをマルチキャストで送信します。
この場合、グループ内に他メンバーがいない為、GET_MBRS_REQメッセージ
に対する応答(GET_MBRS_RSPメッセージ)がありません。
メンバーAは、一定時間誰からも応答がない事を確認すると、
自分がグループ内の最初のメンバーであるとみなし、コーディネーターを
担当する事になります。

----------------------------------------------------------------
※1.コーディネーターとは
コーディネーターは、グループに存在するすべてのメンバー情報を、
グループ全体に通知して共有する役目をしています。
コーディネーターは、グループ内に1メンバーのみ存在しており、
新たにメンバーが参加したり、離脱すると、最新のメンバー情報を
全体に通知しています。
(このようにメンバーを管理する為の仕組みの事を、
「グループメンバーシップ(GMS)」と呼んでいます。)
また、コーディネーターは、後述するMERGE処理にて複数に分かれた
パーディションを結合する為に、定期的にGET_MBRS_REQメッセージ
を送信する事で、グループ内のコーディネーターが自分だけである事を
確認する役目もしています。
----------------------------------------------------------------

・既に1メンバー存在する状態でリスナーを起動した場合



グループ内にメンバーAのみが存在している状態で、メンバーBを起動すると、
メンバーBは、グループ内に存在するコーディネーターの存在を確認する為に、
GET_MBRS_REQメッセージをマルチキャストで送信します。
これを受信したメンバーAは、誰がコーディネーター(この場合はメンバーA)
なのかを知らせる為に、GET_MBRS_RSPメッセージを返信します。

その結果、メンバーBはグループ内のコーディネーターがメンバーAであると
知る為、メンバー管理をおこなっているコーディネーターに対して
グループへの参加依頼となるJOIN_REQメッセージを送信します。
コーディネーターは、JOIN_REQメッセージを受信すると、
最新のメンバーリストをJOIN_RSPメッセージとしてメンバーBに返信します。
これによって、メンバーBは、現在、グループ内に存在する全メンバーの情報
を知る事が出来ます。

----------------------------------------------------------------
※ポイント
他メンバーがGET_MBRS_REQメッセージを受信すると、
GET_MBRS_RSPメッセージとして自分やコーディネーターの情報を返信します。
これにより、グループ内に存在する現在のコーディネーターが誰なのか
を発見し、JOIN_REQメッセージを送信する事でグループに加わる事が出来ます。
また、このようにメンバーやコーディネーターの情報を取得する為の
仕組みを、「ディスカバリプロトコル」と呼ばれています。
----------------------------------------------------------------

----------------------------------------------------------------
ディスカバリプロトコルの種類
PING      ・・・ マルチキャストでGET_MBRS_REQメッセージを送信して、
コーディネーターが誰なのかを発見する。(デフォルト値)
TCPGOSSIP ・・・ コーディネーター役のメンバーを固定IPにする。
TCPPING   ・・・ 事前にすべてのメンバー情報を明示的にリスト化しておく。
MPING     ・・・ ソケットを開いてマルチキャストディスカバリ
メッセージを送受信する。
----------------------------------------------------------------

・既に2メンバーが連携されている状態でリスナーを起動した場合



メンバーA、メンバーBが既にマルチキャスト連携されている状態で
メンバーCを起動した場合、
リスナーを起動時に、GET_MBRS_REQメッセージをマルチキャストで送信します。
GET_MBRS_REQメッセージを受信したメンバーA、メンバーBは、
GET_MBRS_RSPメッセージを返信することで、コーディネーターがメンバーAで
ある事を知る事が出来ます。

メンバーCは、コーディネーターであるメンバーAに対して、
グループに参加する為にJOIN_REQメッセージを送信します。

コーディネーターは、JOIN_REQメッセージを受信後、
最新のメンバーリストをJOIN_RSPメッセージとしてメンバーCに返信します。

コーディネーターは、最新のメンバーリスト(VIEW)をマルチキャストで
送信する事で全メンバーに共有します。
これにより、すべてのメンバーは、[A,B,C]というリストを共有する事になります。

----------------------------------------------------------------
※ポイント
新たにメンバーが加わると、リストの最後尾に追加されます。
上記の場合、メンバーDが参加するとメンバーリストは、
[A,B,C,D]のようになります。
また、メンバーリストの先頭がコーディネーターを担当する事になっており、
メンバーAが離脱すると、[B,C,D]となる為、
メンバーBがコーディネーターとなります。
再度、メンバーAが参加しても、[B,C,D,A]となっている為、
コーディネーターは、メンバーBが継続する事となります。
----------------------------------------------------------------

離脱(REMOVE)
~ 離脱(REMOVE)とは、JGroupsリスナーの停止時にマルチキャストグループ
から抜ける為の仕組みの事です。

・コーディネーターが離脱した場合



離脱するメンバーは、コーディネーター(この場合は、メンバーA自身)に対して、
LEAVE_REQメッセージを送信します。

LEAVE_REQメッセージを受信したメンバーAは、LEAVE_RSPメッセージを
返信します。

コーディネーターは、離脱するメンバーを除いた最新のメンバーリスト
を作成し、マルチキャストでVIEWメッセージを全メンバーに送信します。

メンバーB、メンバーCは、VIEWメッセージを受信する事で最新のメンバー情報
を共有する事が出来ます。
また、この場合メンバーリストが、[B,C]になるので、メンバーBが
コーディネーターとなります。


・コーディネーターでないメンバーが離脱した場合



メンバーBは、コーディネーターであるメンバーAに対して、
LEAVE_REQメッセージを送信します。
これに対し、コーディネーターは、LEAVE_RSPメッセージを返信する
事でメンバーBの離脱が完了します。

また、コーディネーターであるメンバーAは、最新のメンバーリスト
を共有する為、マルチキャストでVIEWメッセージを送信します。

メンバーCは、VIEWメッセージを受信することで、今現在の最新メンバー
を共有する事が出来ます。

----------------------------------------------------------------
※ポイント
マルチキャストグループから離脱する際には、必ず、上記処理が必要になります。
その為、Jgroupsの終了処理を行わずにTomcatを停止しようとした場合、
Tomcatが停止しなくなるという問題が発生します。
(対応方法:ServletContextListenerのcontextDestroyedにて、
JGroupsの終了処理を実行させる。)
----------------------------------------------------------------

JGroupsを利用したクラスタ関連 ~その壱 JGroupsとは ~

JGroupsとは
JGroupsは、Javaで作成された複数のアプリケーション間において、
相互に通信させる為のネットワーク通信ライブラリです。
memcacheなどのキャッシュツールと組み合わせる事で、
クラスタ間でキャッシュのフラッシュをマルチキャスト連携させる事が
出来るようになります。

----------------------------------------------------------------
※ 通常、キャッシュは、各サーバー毎に保存されています。
その為、コンテンツが変更された際に、キャッシュが無効になるまでは、
古い内容のコンテンツが表示されてしまったり、各サーバー毎に
レスポンス内容が異なってしまうという問題が発生してしまいます。
そこで、JGroupsを利用して各サーバー間を連携させる事で、
この問題が解決できるようになります。
----------------------------------------------------------------

マルチキャスト通信とは
マルチキャスト通信は、特定のグループに対してのみデータを転送する
仕組みです。メッセージを受信する側がマルチキャストアドレス
(224.0.0.0~239.255.255.255)を設定することで、
マルチキャストアドレス宛に送信されたデータを、自分あてに
受信出来るようになります。




----------------------------------------------------------------
マルチキャストの利点
・パケットがマルチキャストグループあたりひとつで良いので
ネットワークが混雑しない。(ユニキャストの場合、受信者が増えると、
その数分だけパケットを送信するので、ネットワークが混雑する。)
・ネットワークインタフェースカードで所属していない
マルチキャストグループあてのパケットをフィルタできるので、
非受信者に負荷がかからない。(ブロードキャストだと、パケットは
ひとつで良いが、非受信者のコンピュータに対してもCPU負荷を
かけてしまう。)
----------------------------------------------------------------


JGroupsのパラメーターについて
JGroupsは、通信に利用する各プロトコルの設定値を変更する事が出来ます。
以下は、JGroupsで設定する主なパラメーターになります。

----------------------------------------------------------------
UDP
mcast_addr=231.12.21.132 ・・・ マルチキャストアドレスの指定
mcast_port=45566 ・・・ マルチキャストポートの指定
ip_ttl=4 ・・・ TTLの指定
mcast_send_buf_size=100000 ・・・ 送信するマルチキャストのバッファサイズ
mcast_recv_buf_size=500000 ・・・ 受信するマルチキャストのバッファサイズ
ucast_send_buf_size=100000 ・・・ 送信するユニキャストのバッファサイズ
ucast_recv_buf_size=64000 ・・・ 受信するユニキャストのバッファサイズ
PING
timeout=3000 ・・・ INITIAL_MEMBERSを見つけるために送信されるFIND_INITIAL_MBRSのタイムアウト合計(ミリ秒)。
num_initial_members=2 ・・・ GET_MBR_REQを送信してからtimeoutが経過するか、ここで指定した数のGET_MBR_RSPを受け取るまで待機する。
MERGE2
min_interval=5000 ・・・ FIND_INITIAL_MBRS(GET_MBR_REQを送信してGET_MBR_RSPを取得する処理)を送信する間隔の下限値を設定する。
max_interval=20000 ・・・ FIND_INITIAL_MBRS(GET_MBR_REQを送信してGET_MBR_RSPを取得する処理)を送信する間隔の上限値を設定する。
FD
shun=true ・・・ SUSPECTして除外したメンバーからHEARTBEATが送られてきた場合に、NOT MEMBERを送信して再JOINさせる。
timeout=5000 ・・・ HEARTBEATを送信する間隔。次のHEARTBEATを送信するまでに応答が返ってこない場合はタイムアウト
max_tries=3 ・・・ 指定した回数以上のタイムアウトが発生した場合にFD検知する。
FD_SOCK
VERIFY_SUSPECT
timeout=2000 ・・・ ARE YOU DEADメッセージを送信してから I AM NOT DEADを受け取るまでのタイムアウト
pbcast.NAKACK
retransmit_timeout=600,1200,2400,4800 ・・・ 再送要求までのタイムアウト時間。0.6秒→1.2秒→2.4秒→4.8秒の順に隔を空けて応答を待つ。
gc_lag=20 ・・・ GCラグ(ミリ秒)を設定する。
UNICAST
timeout=400,800,1600,3200 ・・・ ACKメッセージを受信するまでの最大待ち時間(ミリ秒)
pbcast.STABLE
desired_avg_gossip=20000 ・・・ STABLEメッセージを送信する平均時間
FRAG
frag_size=8192 ・・・ このサイズよりも大きなメッセージは、小さく断片化してから送信する。
STATS
pbcast.GMS
join_timeout=5000 ・・・ JOIN_REQを送信してからJOIN_RSPを取得するまでのタイムアウト(ミリ秒)を設定する。
leave_timeout=5000 ・・・ LEAVE_REQを送信してからLEAVE_RSPを取得するまでのタイムアウト(ミリ秒)を設定する。
merge_timeout=10000 ・・・ MERGE_REQを送信してからMERGE_RSPを取得するまでのタイムアウト(ミリ秒)を設定する。
shun=false ・・・ 受信したVIEWに自分が含まれていない場合は、自分をSHUNするか否か
print_local_addr=true ・・・ リスナー時起動時にローカルアドレスをコンソール表示するか否か
----------------------------------------------------------------

ルーティングとバインドアドレスについて注意点
~以下のように複数のネットワークインターフェースが存在する構成となっている場合、
先頭のインターフェースが優先してマルチキャスト通信に利用されます。
以下のように設定する事で、指定したインターフェースを経由して
マルチキャスト通信が利用できるようになります。



----------------------------------------------------------------
# route add -net 231.12.21.0 netmask 255.255.255.0 <インターフェース>
----------------------------------------------------------------

また、IPv6 を利用可能なOSでは、基本となるネイティブソケットが IPv6 になる為、
Javaでは、IPv4よりもIPv6を優先して利用するようになっています。
IPV4を優先するように設定する為には、以下のVMオプションを指定します。

-Djava.net.preferIPv4Stack=true

また、JGroupsは、リスナー起動時に自分のIPアドレスをOSから取得します。
その際も先頭のインターフェースに割り当てられたIPアドレスを利用してしまう為、
マルチキャスト通信で利用するインターフェースに割り当てられたIPアドレスを
バインドアドレスとして指定する為に、以下のVMオプションを指定して下さい。

-Djgroups.bind_addr=

JGroupsの仕組み
~JGroupsは、多くの処理(プロトコル)から構成されており、
それぞれの仕組みが互いに組み合わされる事で1つの機能を担っています。
JGroupsの特徴を理解しておく事は、トラブル発生時に問題解決に役立つ為、
非常に重要です。
次回からは、JGroupsで主要となる以下の機能の特徴について記述しています。

・参加/離脱(JOIN/REMOVE)
・障害検知(FD、FD_SOCK)
・パーティションの結合(MERGE)

2010年6月16日水曜日

JAVAヒープサイズ・GCチューニングのまとめ

■ 前提条件
-----------------------------------------------
JVMは、Sun Java (JDK 1.5-1.6)を想定。


■ 目標
-----------------------------------------------
・マイナーGC、フル GCがそれぞれ頻発しないこと。

・フル GCの実行時間が1秒未満であること。

・マイナーGCの実行時間が0.1秒未満であること。

・連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。

・理想的な状態は、上記に加えて、フル GCの発生が低頻度であること。

具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、TenuringThresholdを超えるマイナーGCを経てNew領域からOld領域へ移動することをできるだけ抑えることがチューニング目標となる。

※Old領域に行ってしまうとフル GCでしか掃除されないため、できるだけOld領域に移る前にNew領域で掃除させる。

※実際のTenuringThresholdが、-XX:MaxTenuringThresholdで指定した値にできるだけ近い状態を維持する。


■ 運用環境で是非設定しておくべきJava起動オプション
-----------------------------------------------
-server ・・・ サーバーモードを有効化
-Xms ・・・ Javaヒープ初期サイズ。一般的に、-Xmxと同値にする
-Xmx ・・・ Javaヒープ最大サイズ
-Xmn(-XX:NewSize) ・・・ New領域初期サイズ。一般的に、-XX:MaxNewSizeと同値にする
-XX:MaxNewSize ・・・ New領域最大サイズ
-XX:PermSize ・・・ Permanent領域初期サイズ。一般的に、-XX:MaxPermSizeと同値にする
-XX:MaxPermSize ・・・ Permanent領域最大サイズ
-verbose:gc(-Xloggc:path_to_file) ・・・ GCログ出力を有効化
-XX:+PrintGCTimeStamps ・・・ GCログにタイムスタンプ(Java起動時からの経過時間)を出力
-XX:+PrintGCDetails ・・・ GCログを詳細に出力(New領域とJavaヒープそれぞれが
どれだけ減ったか出力される)
-XX:+PrintClassHistogram*1 ・・・ SIGQUITシグナル受信時にヒープ統計情報を出力(出力時に強制的にフル GCが発生)。-verbose:gc(-Xloggc:path_to_file)と併用必須。
なお、SIGQUITシグナルを送信するには、kill -3 を実行すればよい
-XX:+HeapDumpOnOutOfMemoryError 
・・・ OutOfMemoryError発生時にヒープダンプを出力


■ 運用環境で設定しておいた方がいいJava起動オプション
-----------------------------------------------
-XX:SurvivorRatio ・・・ Eden領域のサイズをS0またはS1領域のサイズで割った値(S0とS1領域は同じサイズ)


-XX:MaxTenuringThreshold 
・・・ New領域において、オブジェクトがマイナーGCを何回超えて生き残ると、Old領域に移動するかのしきい値の最大値(実際のしきい値は、1からMaxTenuringThresholdの範囲で動的に決定される)

-XX:TargetSurvivorRatio ・・・ Survivor領域がいっぱいと判断される使用率


■ チューニング(トラブル対応)のためのコマンド、ツール
-----------------------------------------------
1.GC発生状況、メモリリーク状況

 -verbose:gc(-Xloggc:path_to_file)
 -XX:+PrintGCTimeStamps
 -XX:+PrintGCDetails

 を設定しておくことでGCログが取得できる。取得したGCログは、侍やGCViewer等でグラフ化できる。


2.ヒープ使用状況

 jstatコマンドでリアルタイムに確認可能。
 (-gcutilオプションで、S0、S1、Eden、Old、Permanent領域ごとの使用率やマイナーGC、フル GCの発生回数、GCの実行時間累計が確認可能)

 jstat -gcutil -h10 5000

 jconsoleコマンドを使用すれば、GUIでリアルタイムに確認することも可能。


3.ヒープ統計情報

 以下の方法で出力できる。

 -verbose:gc(-Xloggc:path_to_file)、-XX:+PrintClassHistogramを設定しておき、kill -3 を実行
 jmap -histo

 ヒープ中のオブジェクトのインスタンス数、サイズ一覧が出力される。
 ヒープダンプの出力に比べて、取得時の負荷は小さいが、分析は大変。


4.ヒープダンプ

 以下の方法で出力できる。

 -XX:+HeapDumpOnOutOfMemoryErrorを設定しておき、OutOfMemoryErrorが発生
 -XX:+HeapDumpOnCtrlBreak*2を設定しておき、kill -3 を実行
 jmap -heap:format=b (Java 1.5の場合)
 jmap -dump:format=b,file=filename (Java 1.6の場合)

 出力に時間もかかる(ヒープサイズ512MBで5-10分程度)し、負荷も大きいが、詳細なヒープ情報を取得可能。ダンプファイルはバイナリなので、以下のツールで分析する。

 ・Eclipse Memory Analyzer
 ・HeapAnalyzer
 ・HAT


5.プロファイラ

 オブジェクトの生成、GC等、JVMの挙動をトレースする。アプリケーションを動作させつつ、増加していくオブジェクトを探したり、スタックトレースを確認したり等の調査が可能。
 パフォーマンスが悪化するため、運用環境では通常使用できない。
 メモリリークやメモリの大量消費の調査の場合、まず問題の再現方法を突き止めた上で、開発/検証環境でプロファイラを使用して、再現方法を実施して、増加したオブジェクトを解析する。

 ・NetBeans Profiler


6.スレッドダンプ

 ヒープ、GCチューニングの観点ではないが、アプリケーションの応答がとまってしまったらとりあえず取得するのがよい。kill -3 で出力される。
 スレッドのデッドロックが発生していないか、大量の待ち行列が発生していないか等がわかる。


■ ケース別チューニング(トラブル対応)方法
-----------------------------------------------
1.OutOfMemoryError: PermGen space と出る場合

 Permanent領域不足によるOutOfMemoryErrorが発生している。

 対応としては、-XX:PermSize、-XX:MaxPermSizeを指定し、OutOfMemoryErrorが発生しないようにPermanent領域を広げてやればよい。
 ただし、基本的にPermanent領域は、クラス情報やメソッド情報が格納される領域であり、アプリケーション起動後はほとんど増減しない。
 jstatやjconsole等でPermanent領域の使用状況を確認し、もし増加が続くようであれば、Permanent領域のメモリリークが発生している可能性がある。

 リーク箇所を発見するには、ヒープ統計情報やヒープダンプを数回取得して比較したり、アプリケーションログ等からOutOfMemoryError発生直前に実行されている処理がいつも同じでないか等を確認する。

 例えば、DIコンテナは通常1アプリケーションで1つしか使用しないが、とある処理で新規にコンテナを生成するようになっていて、その処理が実行されるたびに大量のPermanent領域を消費し、ついにはOutOfMemoryErrorが発生した事例がある。

2.OutOfMemoryError: Java Heap Space と出る場合(OutOfMemoryErrorとしか出ないこともある)

 ヒープ不足によるOutOfMemoryErrorが発生している。

 とりあえずの対応としては、-Xms、-Xmxを指定し、OutOfMemoryErrorが発生しないようにヒープを広げてやればよい。

 根本対応としてはまずは、GCログを取得し、ヒープでのメモリリークが発生していないか確認する必要がある。
 GCログを侍やGCViewer、Excel等でグラフ化して確認する。
 グラフがフル GCを跨って、右肩上がりになっている(右肩上がりになってフル GCでいったん下がるが、スタート時ほど下がっていない。複数回のフル GC発生時の下限値を結ぶ線が右肩上がりになっている)場合は、メモリリークが発生している可能性が高い。
 リーク箇所を発見するには、ヒープ統計情報やヒープダンプを数回取得して比較して、フル GCを経ても増加し続けているオブジェクトを探す。
 怪しいオブジェクトが見つかれば、NetBeans Profiler等を使用して、オブジェクトの使用箇所を探し、オブジェクト参照を追跡する。

3.ヒープチューニング方法

 運用環境で、jstat -gcutilやjconsoleを使用してヒープの各領域の使用状況を確認しながら、フル GC実行時間を最小にするために、OutOfMemoryErrorが発生しないサイズでなるべく小さいサイズを-Xms、-Xmxに指定し、また、フル GC発生頻度を抑えるために、

 -Xmn(-XX:NewSize)
 -XX:MaxNewSize
 -XX:SurvivorRatio
 -XX:MaxTenuringThreshold
 -XX:TargetSurvivorRatio

 を調整して、なるべくNew領域でのマイナーGCでメモリを解放させて、Old領域へ移動される頻度、サイズを減らすようにする。

 マイナーGCが発生していないのに、いきなりOld領域の使用率が上がった場合や、S0、S1、Eden領域がいきなり100%になった場合は、オブジェクトのサイズがS0、S1、Eden領域サイズよりも大きい。
 アクセスログと突き合わせて、使用率のあがるURLを特定し、コードを見たり、URLアクセス前後のヒープ統計情報、ヒープダンプを比較することで、サイズの大きいオブジェクトを特定する。
 もし、そのオブジェクトが短命オブジェクトの場合は、-Xmn(-XX:NewSize)、-XX:MaxNewSizeを増加させて、Old領域に行かないように調整する。
 とりあえずは、以下のような値からはじめて調整していく。

 -Xmn(-XX:NewSize)
 -XX:MaxNewSize
 -Xmxサイズの1/4 - 1/3程度
 -XX:SurvivorRatio 2 - 8程度
 -XX:MaxTenuringThreshold 32程度
 -XX:TargetSurvivorRatio 80 - 90程度

4.マイナーGC実行時間が1秒を超える場合

 New領域が大きすぎる可能性があるので、-Xmn(-XX:NewSize)、-XX:MaxNewSizeを減らす。

 CPUが複数ある(マルチコアを含む)場合は、-XX:+UseParallelGC オプションでパラレルGCを有効にする。
 -XX:+UseParallelGC ・・・ マイナーGCをマルチスレッドで実行

5.フル GC実行時間が1秒を超える場合

 まずは、メモリリークが発生していないか確認する。
 確認方法は、2.OutOfMemoryError: Java Heap Space と出る場合 を参照。

 メモリリークが発生していない場合は、Old領域が大きすぎる可能性があるので、-Xms、-Xmxを減らす。減らしすぎて、OutOfMemoryErrorを発生させないように注意する。やり方は、3.ヒープチューニング方法 を参照。

 メモリリークが発生しておらず、これ以上減らすとOutOfMemoryErrorが発生するOld領域サイズなのに、フル GC実行時間が1秒を超える場合は、以下の対応案が考えられる。

 (1)アプリケーションでメモリを使いすぎていないか確認し、使いすぎている場合は修正する

  メモリを多く消費する処理を特定するには、運用環境で、jstat -gcutilやjconsoleを使用してヒープの各領域の使用状況を監視し、使用率がドカッとあがったときに実行された処理を、アクセスログから突き止める。(ある程度絞れれば、あとは開発/検証環境で突き止める)あとは、コード解析を行い、修正する。

 (2)セッションタイムアウト時間の確認

  セッションタイムアウト時間が不必要に長すぎないか確認し、長い場合は短くする。

 (3)コンカレントGCの使用

  フル GCをできるだけアプリケーションをとめずに並行実行するコンカレントGCを使用する。以下のJava起動オプションを設定する。

  -XX:+UseConcMarkSweepGC ・・・ コンカレントGCの有効化
  -XX:+CMSParallelRemarkEnabled 
・・・ フル GCのRemarkフェイズをマルチスレッドで実行
  -XX:+UseParNewGC ・・・ マイナーGCをマルチスレッドで実行

6.アプリケーションの応答が停止(フリーズ)した場合

 スレッドダンプを取得する。

7.StackOverflowError と出る場合

 StackTraceを確認し、メソッドの不要な再帰呼び出し等が行われていないか確認する。あるいは、以下のJava起動オプションを設定し、スタックサイズを増やしてみる。

 ・HotSpot VMの場合
  -Xss 
(Java/ネイティブ)スレッドのスタックサイズ
  -Xoss 効果なし

 ・非HotSpot VMの場合
  -Xss ネイティブスレッドのスタックサイズ
  -Xoss Javaスレッドのスタックサイズ


2010年6月14日月曜日

Apache RewriteRule設定 サンプル

Apache RewriteRule設定 サンプル


■/hoge/ を /fuga/ に rewrite(リダイレクト)する。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/$ /fuga/
-------------------------------------------------------


■/hoge/ 以下を /fuga/ 以下にまとめて rewrite(リダイレクト)する。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/(.*)$ /fuga/$1
-------------------------------------------------------


■/hoge/ 以下で末尾が .jpg のリクエストのみを /fuga/ 以下に rewrite(リダイレクト)する。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/(.*\.jpg)$ /fuga/$1
-------------------------------------------------------


■/hoge/ 以下で末尾が .jpg か .gif のリクエストのみを /fuga/ 以下に rewrite(リダイレクト)する。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/(.*)\.(jpg|gif)$ /fuga/$1.$2
-------------------------------------------------------


■/cgi-bin/hoge/fuga を /cgi-bin/example.cgi?q=hoge&opt=fuga に rewrite(リダイレクト)(いわゆる、動的アドレスを静的アドレスに変換するってやつ)
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/cgi-bin/([0-9A-Za-z]+)/([0-9A-Za-z]+)$ /cgi-bin/example.cgi?q=$1&opt=$2
-------------------------------------------------------

■リダイレクト時のブラウザのURL欄
mod_rewrite で rewrite(リダイレクト)処理を行ったとき、以下のようにサーバパスで rewrite(リダイレクト)させると、ブラウザのURL欄は書き換わらない。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/$ /fuga/
-------------------------------------------------------


例えば、
http://www.ise-web.com/hoge/ にアクセスすると、
http://www.ise-web.com/fuga/ の中身が、
URL欄は http://www.ise-web.com/hoge/ のまま表示される。


しかし、以下の例では、リダイレクトと同時にURL欄が書き換わる。
-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/$ /fuga/ [R=301]
-------------------------------------------------------

-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/$ /fuga/ [R=302]
-------------------------------------------------------

-------------------------------------------------------
RewriteEngine on
RewriteRule ^/hoge/$ http://www.ise-web.com/fuga/
-------------------------------------------------------

最後の URL にリダイレクトさせるパターンは、同じサーバ内の URL であっても、飛び先を URL で記述するとブラウザのURL欄が書き換わります。
同一サーバ内であれば、URLにリダイレクトさせると無駄にログも増えるのであまりオススメしません。
■%2F問題

Apache1.X 系で mod_rewrite を使う場合、URLに「%2F」が含まれると思い通りに動作しない問題があります。
(Apache2.X 系でも同様ですが、Apache2.0.46 以降では「AllowEncodedSlashes On」により回避できます。)


例えば、以下のような書き換えを記述したとします。
RewriteEngine on
RewriteRule ^/keyword/(.*)$ /cgi-bin/script.cgi?k=$1

想定としては、
http://www.ise-web.com/keyword/hogefuga というアクセスに対して
http://www.ise-web.com/cgi-bin/script.cgi?k=hogefuga の結果を返します。


hogefuga の部分が色々と変化するわけです。


この際、
http://www.ise-web.com/keyword/hogefuga/hage は
http://www.ise-web.com/cgi-bin/script.cgi?k=hogefuga/hage となりますが、


http://www.ise-web.com/keyword/hogefuga%2Fhage は
http://www.ise-web.com/cgi-bin/script.cgi?k=hogefuga%2Fhage とならず、404エラーになります。


直接、
http://www.ise-web.com/cgi-bin/script.cgi?k=hogefuga%2Fhage にアクセスするとこの問題は起きません。


先にも書きましたが、Apache2.0.46 以降では httpd.conf に「AllowEncodedSlashes On」を記述することにより回避できます。
しかし、Apache1.X の環境ではなかなか回避できずにはまる要素だと思います。
■アクセスを拒否する
どこかにリダイレクトするのではなく、特定のアクセスにエラーを返せます。


■.htaccess へのアクセスを拒否する。
-------------------------------------------------------
RewriteEngine On
RewriteRule \.htaccess - [F]
-------------------------------------------------------


■/hoge/ 以下へのアクセスに 403 Forbidden を返します。
-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hoge/.* [F]
-------------------------------------------------------


■/hage/ 以下へのアクセスに 410 Gone を返します。
-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hage/.* [G]
-------------------------------------------------------

■複数の RewriteRule
RewriteRule は複数かけます。


■/hoge/ 以下を /fuga/ 以下にリダイレクとした上に /fuga/hage/ 以下のものは /foo/ 以下にリダイレクトする。
-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hoge/(.*) /fuga/$1
RewriteRule ^/fuga/hage/(.*) /foo/$1
-------------------------------------------------------


上の例で、/hoge/ 以下を /fuga/ 以下にリダイレクとさせた時点で処理を終わらせる、つまり次のリダイレクトを実行させないようにするには [L] を付加します。


-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hoge/(.*) /fuga/$1 [L]
RewriteRule ^/fuga/hage/(.*) /foo/$1
-------------------------------------------------------

■RewriteRule のオプション
これ以外にもいろいろありますが。


■HTTPステータスコードを吐く [R=ステータスコード]
-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hoge/(.*) /fuga/$1 [L,R=301]
RewriteRule ^/fuga/hage/(.*) /foo/$1
-------------------------------------------------------


■大文字、小文字を区別しない [NC]
-------------------------------------------------------
RewriteEngine On
RewriteRule ^/hoge/(.*) /fuga/$1 [NC,L]
RewriteRule ^/fuga/hage/(.*) /foo/$1
-------------------------------------------------------

■ある条件が揃ったらリダイレクト
RewriteCond を使えば、ある条件に合致したときだけリダイレクトするということも、もちろん可能です。


■HTTP_HOST が www.ise-web.com だったら RewriteRule を適用する。
-------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.ise-web.com$
RewriteRule ^/(.*) /$1
-------------------------------------------------------


■HTTP_HOST が www.ise-web.com じゃなかったら RewriteRule を適用する。
-------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.ise-web.com$
RewriteRule ^/(.*) /$1
-------------------------------------------------------


■HTTP_HOST が www.ise-web.com で HTTP_USER_AGENT に MSIE が含まれていたら RewriteRule を適用する。
-------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.ise-web.com$
RewriteCond %{HTTP_USER_AGENT} MSIE
RewriteRule ^/(.*) /$1
-------------------------------------------------------


RewriteCond を複数並べると AND でつながっていく。OR にしたい場合は [OR] をつける。


■HTTP_HOST が www.ise-web.com であるか、または HTTP_USER_AGENT に MSIE が含まれていたら RewriteRule を適用する。
-------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.ise-web.com$ [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE
RewriteRule ^/(.*) /$1
-------------------------------------------------------


RewriteCond の条件で大文字、小文字を区別しない場合は [NC] をつける。


■HTTP_USER_AGENT に MSIE や msie や MsIe や MSiE などが含まれていたら RewriteRule を適用する。
-------------------------------------------------------
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} MSIE [NC]
RewriteRule ^/(.*) /$1
-------------------------------------------------------


RewriteCond で対象となる変数には以下のようなものがあります。


HTTP_USER_AGENT / HTTP_REFERER / HTTP_COOKIE / HTTP_FORWARDED / HTTP_HOST / HTTP_PROXY_CONNECTION / HTTP_ACCEPT
REMOTE_ADDR / REMOTE_HOST / REMOTE_USER / REMOTE_IDENT / REQUEST_METHOD / SCRIPT_FILENAME / PATH_INFO / QUERY_STRING / AUTH_TYPE
DOCUMENT_ROOT / SERVER_ADMIN / SERVER_NAME / SERVER_ADDR / SERVER_PORT / SERVER_PROTOCOL / SERVER_SOFTWARE
TIME_YEAR / TIME_MON / TIME_DAY / TIME_HOUR / TIME_MIN / TIME_SEC / TIME_WDAY / TIME
API_VERSION / THE_REQUEST / REQUEST_URI / REQUEST_FILENAME / IS_SUBREQ


以上、かんたんな mod_rewrite サンプル集でした。



2010年1月3日日曜日

Express5800/110Ge-s RAID構築手順

1.マザーボード上のジャンパスイッチの設定を「RAID]に変更します。

2.RAIDシステム管理ユーティリティを起動します。

・電源投入後、キーを押します。

  ・POST画面で、以下の表示を確認したら、キーを押します。

  ・ユーティリティが起動し、TOPメニューが表示されます。

3.Configurationを新規作成します。

  ・TOPメニューより、「Configure」→「New Configuration」を選択します。

  ・確認メッセージ(Proceed?)が表示されるので、YESを選択します。

  ・SCANDEVICEが開始され、「READY」と表示された画面が表示されます。

  ・カーソルキーでパックしたいハードディスドライブにカーソルを合わせ、スペースキーを押します。
  「READY」から「ONLIN」になります。

  ・F10を押して、Select Configurable Arraysを選択する。
  スペースキーを押すと、SPAN-1が設定されます。

  ・F10を押して、バーチャルドライブの作成を行う。
  ハードディスクドライブ2台、RAID1に設定します。

---------------------------------------------

RAID
RAIDレベル  RAID1に設定します。

Size
バーチャルドライブのサイズ  最大容量に設定にします。

DWC
Disk Write Cache  性能面を重視するためONに設定します。

RA
Read Ahead  先読みを行うためONに設定します。

SOAN
Span設定  NOに設定します。

---------------------------------------------

すべての設定が完了したら、「Accept」を選択して、キーを押します。


4.設定を保存します。

  ・キーを押して画面を抜け、「Save Configuration?」画面まで戻り、「Yes」を選択します。

  ・Configurationのセーブ完了メッセージが表示されたら、キーでTOPメニューまで戻ります。

  ・TOPメニューより、「Objects」-「Virtual Drive」-「View/Update Parameters」を選択してバーチャルドライブの情報を確認します。

  ・TOPメニューより、「Initialize」を選択します。

  ・「Virtual Drive」の画面が表示されたら、イニシャライズを行うバーチャルドライブにカーソルを合わせて、スペースキーを押します。
  バーチャルドライブを選択後、キーを押して、Initializeを行います。
  実行確認が表示されるので、YESを選択します。

5.整合性チェックを行います。

  ・TOPメニューより、「Check Consistency」を選択します。

  ・「Virtual Drives」画面が表示されます。

  ・整合性チェックを行うバーチャルディスクにカーソルを合わせて、キーを押します。