JavaでプロセスIDを取得する方法

プロセスの PID を記録してデーモンの起動と終了を行うといった Unix 系のサーバで一般的に行われている手法を Java VM で行うためなどに VM のプロセス ID が取れたらと何時も思っておりましたが、実際にやろうと思うと JNI を使用して環境ごとのネイティブライブラリを作らなければならなかったりと一々面倒です。

たまたま JMX (Java Management Extensions) を使ってサーバ管理系の MXBean などを作っておりましたところプロセス ID らしきものが目についたのでここにメモしておきます。やり方は簡単、RuntimeMXBean を使用するだけです。

import java.lang.management.*;

RuntimeMXBean rt = ManagementFactory.getRuntimeMXBean();
String name = rt.getName();
if(name.matches("\\d+@.*")){
    pid = Integer.parseInt(name.substring(0, name.indexOf('@')));
} else {
    // 取得できなかった場合
    pid = -1;
}

上記のように RuntimeMXBean#getName() は "pid@hostname" という形式の文字列を返しますので解析してプロセス ID を取り出すことができます。もちろん環境依存の挙動であるためすべての実行環境でうまく取得できる保証はありませんが、特定の環境向け開発だとか、ネイティブライブラリを用意するのはこの方法がうまく行かなかった環境だけと割り切るだけでも楽かと思います。

手元で確認できた環境は以下の通り。他にあればコメントなどに残しておいてもらえると助かります。

• Oracle JDK 1.6.0_26 (CentOS 5.6 final)
• Oracle JDK 1.6.0_24 (Windows XP)
• Apple JDK 1.6.0_26 (MacOSX 10.5)

mediawiki 1.16.0 + PostgreSQL 9.0 セットアップ

MediaWiki 1.16.0 のバックエンドに PostgreSQL 9.0 を使用する手順について記述しています。とはいえ MySQL の方が世界シェアは大きいですし、tsearch2 を導入しなければならないなどで若干煩雑ですので、全く新規に mediawiki を使用するのであれば MySQL の方をお勧めします。ここは「MySQL なんてへなちょこ DB はいやだ!」という変態様のための記事です。

• OS: CentOS release 5.5 (Final)

read more...

今年最後のスケキヨさん

10/12/31 12:49, 13kB, 240x320, W61CA

MediaWiki 1.16.0 のバックエンドを PostgreSQL 8.3 から MySQL 5.5.8 へ移行しようと試みた際のまとめである。結論として、仕事として 2～3 日つきっきりの作業でもしなければ無理っぽいという事が分かった。

移行作業自体は以下の様にできると思ったのだが…

1. MySQL 上に初期状態の MediaWiki データベースを作成 (定義のみが必要なのでデータは全てTRUNCATEした)。
2. pg_dump で --format plain --data-only --column-inserts オプションを指定し全データの INSERT 文を取得。
3. MySQL に適合するように SQL を手直ししつつ try and error で流し込み。

しかしそう簡単には行かなかった。以下、作業で気付いた点などを書いておくので誰か挑戦してみようと思う人がいれば試してみると良い。

• MySQL はスキーマを使用していない。一つのDBインスタンスに複数の MediaWiki スキーマを定義している場合はそれぞれ別のDBにしなければならない (接頭字を付ければ混在は可能だが面倒)。
• PostgreSQL のシーケンスは MySQL では AUTO INCREMENT カラムになっており、シーケンスに相当する現在値は移行しなくても良い (AUTOINCREMENTカラムが自動でMAX(COLUMN)+1を与えてくれる)。
• PostgreSQL と MySQL で名前の異なるテーブルが二つ (mwuser→user,pagecontent→text)、また PostgreSQL では tsearch2 用の追加カラムを持つテーブルが二つ存在する。
• 日時カラムは PostgreSQL が TIMESTAMP 型を使っているのに対して MySQL は BINARY(14) (ただし TIMESTAMP を使用しているテーブルが1つだけある)。従って日時データの表現形式を '2010-12-31 00:00:00+09' から '20101231000000' に変換する必要あり。
• PostgreSQL で TEXT 型 (長さ無制限) だった多くが TINYBLOB (最大255バイト) になっている。従って内容を壊さないよう手動で文章を切り詰める必要がある。ページ間リンクの管理テーブルなどで矛盾が出そう。
• シーケンスを使う PostgreSQL の user_id は 0 起源、AUTO INCREMENT を使う MySQL の user_id は 1 起源。つまり移行で USER ID を変えなければならない。他のテーブルはユーザ名で識別しているようだが影響範囲に確証が持てない。

単純なテーブル名変更やデータの表現変更であればそれほど大きな影響はないかと思うが、さすがに ID 値まで変えるのは苦労して移行しても矛盾が発生しそうなので諦めることにした。

スキーマにしても TIMESTAMP にしても MySQL は過去の負の遺産を引きずっている設計であることが分かる。PostgreSQL の方が外部制約まできちんと設計している。