ふたつの川うるおう日記 http://jfut.integ.jp Wed, 20 Jan 2010 13:24:21 +0000 http://wordpress.org/?v=2.9.2 ja hourly 1 古いサーバでJDK 6 Update 18に更新したらタイムゾーンがJSTからGMTに変わった件と対処法 http://jfut.integ.jp/2010/01/20/jdk-6-update-18-default-timezone-on-old-server/ http://jfut.integ.jp/2010/01/20/jdk-6-update-18-default-timezone-on-old-server/#comments Wed, 20 Jan 2010 13:09:50 +0000 jfut http://jfut.integ.jp/?p=910

とある古いサーバにインストールされているJDK 6 Update 17をJDK 6 Update 18に更新したらデフォルトのタイムゾーンがJSTからGMTに変わってしまいました。他のサーバでは問題なかったのでこの古いサーバ限定の問題です。

状況を確認するためにサンプルコードを動かして確認しました。

import java.util.Date;

public class DateTest {
    public static void main(String[] args) {
        System.out.println(new java.util.Date());
    }
}

実行してみます。

# /usr/local/java/jdk1.6.0_17/bin/java DateTest
Wed Jan 20 21:42:44 JST 2010
# /usr/local/java/jdk1.6.0_18/bin/java DateTest
Wed Jan 20 12:42:56 GMT 2010

というようにJDK 6 Update 17ではJSTなのにJDK 6 Update 18だとGMTになってしまいました。JVMのタイムゾーンがGMTになる 追記と同じ原因のようで、/etc/localtime を調べてみたら /usr/share/zoneinfo/Asia/Tokyo と違うものでした。

# ls -al /etc/localtime
-rw-r--r--  1 root root 73 Feb 26  2004 /etc/localtime
# ls -al /usr/share/zoneinfo/Asia/Tokyo
-rw-r--r--  2 root root 125 Mar 22  2006 /usr/share/zoneinfo/Asia/Tokyo

というわけで、コピーして直します。

cp -a /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

再び確認します。

# /usr/local/java/jdk1.6.0_17/bin/java DateTest
Wed Jan 20 21:49:58 JST 2010
# /usr/local/java/jdk1.6.0_18/bin/java DateTest
Wed Jan 20 21:50:07 JST 2010

無事直りました。良かった良かった。

/etc/localtime が食い違ってのは、/etc/localtimeのタイムスタンプが2004-02-26 という古いサーバなので、インストール時に何かミスったか、これまでの運用の中での更新で何かがおきたのかなと思います。ただ、JDK更新したらいきなしWEBアプリが書き込むデータのタイムスタンプが9時間ずれ初めてたのでビックリしました。

]]> http://jfut.integ.jp/2010/01/20/jdk-6-update-18-default-timezone-on-old-server/feed/ 0 Cubbyのアクションクラスで定数を利用してリファクタリングしやすくする http://jfut.integ.jp/2010/01/11/cubby-actionclass-with-static-field/ http://jfut.integ.jp/2010/01/11/cubby-actionclass-with-static-field/#comments Mon, 11 Jan 2010 03:10:12 +0000 jfut http://jfut.integ.jp/?p=884

Cubbyのアクションクラスにはバリデーションルールの定義時やアノテーションに文字列が登場します。文字列で指定しているのでリファクタリングする時に修正漏れなどがおきそうでちょっと怖いです。そこで、それらの文字列を定数にしてしまえば、少しだけリファクタリングしやすくなりそうです。また、IDE上での参照元・参照先への移動や使われているかどうかのチェックも簡単になります。

例えば、次のようなアクションクラスがあるとします。

@Path("hoge")
public class HogeAction extends AbstractAction {

    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add("token", new TokenValidator());
                add("name", new TokenValidator());
                add("comment", new TokenValidator());
            }
        };

    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

これを次のようにします。

import static org.example.test.entity.names.Names.*;

@Path("hoge")
public class HogeAction extends AbstractAction {

    private static final String processApplyValidationName
        = "processApplyValidation";
    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add(TOKEN, new TokenValidator());
                add(post().name().toString(), new TokenValidator());
                add(post().comment().toString(), new TokenValidator());
            }
        };

    private static final String hogeParameterDtoName = "hogeParameterDto";
    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form(hogeParameterDtoName)
    @Validation(rules = processApplyValidationName, errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

変更した箇所を説明します。

説明

S2JDBC-GenのNamesクラス内のstatic関数をStatic Import

import static org.example.test.entity.names.Names.*;

S2JDBC-Gen 2.4.40で導入されたNamesクラス内のstatic関数をStatic Importします。バリデーションルールのinitialize()内で使います。

バリデーションルールの変数名を定数定義

private static final String processApplyValidationName = "processApplyValidation";

バリデーションルールprocessApplyValidationの変数名を表す定数です。アクションメソッドの @Validation にはここで指定した定数を使うようにすることでリファクタリングしやすくします。

バリデーションルール: TokenValidatorに使用するパラメータの定数化と使用

add(TOKEN, new TokenValidator());

Cubbyで標準提供されている2重サブミットを検証するTokenValidatorで仕様するパラメータ名を指定します。TOKEN は AbstractAction で次のように定義しておきます。

protected static final String TOKEN = "token";

この例では、パラメータ名に "token" を使用しています。

バリデーションルール: リクエストパラメータに定数を使用

add(post().name().toString(), new TokenValidator());
add(post().comment().toString(), new TokenValidator());

本来NamesクラスからStatic Importした静的関数はS2JDBCでjoinやwhereで指定するのに使うのに便利な関数ですが、ここではその文字列表現を流用してパラメータの指定に使用します。例ではテーブルpostが持つ属性名nameとcommentの文字列表現を流用しています。

リクエストパラメータ名とテーブルの属性名は一緒なことが多いと思うので、多くの場合で流用できると思います。これでS2JBDC同様バリデーションの項目名もリファクタリングしやすくなります。

リクエストパラメータのバインド先の変数名を定数定義

private static final String hogeParameterDtoName = "hogeParameterDto";

バリデーションルールの変数名同様、リクエストパラメータのバインド先hogeParameterDtoの変数名を表す定数です。アクションメソッドの @Form にはここで指定した定数を使うようにすることでリファクタリングしやすくします。

@Form で定数を使用する

...
@Form(hogeParameterDtoName)
...
public ActionResult processApply() {
    ...
}

先に定義した リクエストパラメータのバインド先hogeParameterDtoの変数名 をアクションメソッドに対するアノテーション @Form に指定します。

@Validation で定数を使用する

...
@Validation(rules = processApplyValidationName, errorPage = "/hoge/edit.html")
...
public ActionResult processApply() {
    ...
}

先に定義した バリデーションルールprocessApplyValidationの変数名 をアクションメソッドに対するアノテーション @Validation に指定します。

以上です。

やろうと思えば、@Path や @OnSubmit などでも定数を使えますがそこは定数にしていません。@OnSubmitはHTMLファイルの中身と対応するので定数化してもリファクタリングのしやすさには影響しないですが、@PathはHTMLファイル名の変更や移動の時に使えるので定数化しても良いかもしれないですね。

]]> http://jfut.integ.jp/2010/01/11/cubby-actionclass-with-static-field/feed/ 0 Cubbyでアクションメソッドに指定するアノテーションの順番 http://jfut.integ.jp/2010/01/10/cubby-actionmethod-annotation-order/ http://jfut.integ.jp/2010/01/10/cubby-actionmethod-annotation-order/#comments Sun, 10 Jan 2010 03:41:33 +0000 jfut http://jfut.integ.jp/?p=855

しばらく時間が空いてからCubbyを使ったWEBアプリケーションを書く時に、アクションメソッドに指定するアノテーションの順番どうだったかなっと考えるのでまとめます。アノテーションなので適当な順番に書いても問題なく動作しますが、処理の流れを考えて次の順番で指定しています。

  1. URIを指定: @Path
  2. HTTPメソッドを指定: @Accept
  3. 同一URIへのPOST時などに実行するアクションメソッドを変える指定: @OnSubmit
  4. リクエストパラメータのバインド先を指定: @Form
  5. リクエストパラメータのバリデーションを指定: @Validation
@Path("hoge")
public class HogeAction extends AbstractAction {
    ...
    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }
    ...
}
]]> http://jfut.integ.jp/2010/01/10/cubby-actionmethod-annotation-order/feed/ 0 JIRA 4.xと新しいPlugin機構 http://jfut.integ.jp/2010/01/04/jira4-and-new-plugin-infrastructure/ http://jfut.integ.jp/2010/01/04/jira4-and-new-plugin-infrastructure/#comments Mon, 04 Jan 2010 05:44:31 +0000 jfut http://jfut.integ.jp/?p=822

Seasarプロジェクトでも利用しているJIRA のライセンスを去年の10月に自分用に購入しました。JIRAを開発しているAtlassian社が10ユーザまで利用できるGet Started for $10というライセンスを始めたので思わず買いました。JIRA 4.0になって、JIRA 3.x以前にあったエディションの違いが無くなり、$10でEnterpriseエディションが使えるというのは破格です。JIRA 3.xまではLDAPサポートにEnterprise以上が必要でとても買える金額では無かったため嬉しいです。また、このライセンスの購入費用は全額 Room to Read に寄付されるプログラムになっています。

日本円で購入したい場合は、Atlassian社のOfficial Atlassian Partnerである リックソフト株式会社 が1,050 円で販売されています。

そんなわけで、だいぶ前置置きが長くなりましたが、自分用にJIRAの環境を作りました。購入当初JIRA 4.0には 新しく導入されたガジェットの仕組みがSSL環境で上手く動かない問題 があったので、使い始めたのはこの問題がJIRA側で解決した4.0.1からです。

ただ、まだ問題があって、Seasarプロジェクトで利用していた3.xのインストール手順でwarファイルを作成し、Tomcatにデプロイするとエラーがでて上手く起動しないのです。いろいろ試してみると自分で追加していたPluginを全部外すと起動しました。そんなことをつぶやいていたらリックソフトのohnukiさんがコンタクトをくださっていろいろやりとりした結果、原因が判明しました。

原因は、JIRA 4.0からOSGiを使用した新しいPlugin機構(Version 2)がサポートされ、JIRA 3.xの時とPluginの配置の仕方が変わっていたことでした。これに気付かず、JIRA 3.xの導入の仕方で入れていたので上手くPluginがロードされなかったようです。一応、互換性のため、古いPluginの配置方法(Version 1)も使えるようですが、Tomcat 5.5.28では動作するものの、Tomcat 6.0.20では動作せず、それでエラーが出ていました。

  • 参考: Managing JIRA’s Plugins
    • Version 1: atlassian-jira/WEB-INF/lib/ 以下に配置
    • Version 2: jira.home/plugins/installed-plugins/ 以下に配置
      • jira.home はJIRA 4.0から導入されたホームディレクトリ指定

というわけで、無事やっとPluginも使えるようになりました。ohnukiさんありがとうございました！

Pluginが使えるようになったので、SeasarプロジェクトのJIRAも近日アップグレードのテストをし、アナウンスを出した後に現在の3.13.5から4.0.1に更新したいと思います。

以下、何かの参考までにVersion 1 + Tomcat 6.0.20で起動した時の例外全文を記載しておきます。

起動時のエラー内容

  • 環境
    • Sun JDK 1.6.0_17 64-Bit Server VM
    • JIRA 4.0.1 + Version 1の方法でのPlugin導入
      • JIRA Calendar Plugin 1.12
      • JIRA Charting Plugin 1.5
    • Tomcat 6.0.20
2010/01/04 13:18:33 org.apache.catalina.core.StandardContext listenerStart
致命的: クラス com.atlassian.jira.upgrade.ConsistencyLauncher のリスナインスタンスにコンテキスト初期化イベントを送信中の例外です
java.lang.ExceptionInInitializerError
	at org.objectweb.jotm.Current.<init>(Current.java:121)
	at org.objectweb.jotm.UserTransactionFactory.getObjectInstance(UserTransactionFactory.java:45)
	at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
	at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
	at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137)
	at javax.naming.InitialContext.lookup(InitialContext.java:392)
	at org.ofbiz.core.entity.transaction.JNDIFactory.getUserTransaction(JNDIFactory.java:109)
	at org.ofbiz.core.entity.TransactionFactory.getUserTransaction(TransactionFactory.java:91)
	at org.ofbiz.core.entity.TransactionUtil.getStatus(TransactionUtil.java:80)
	at org.ofbiz.core.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:369)
	at org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:416)
	at org.ofbiz.core.entity.GenericDAO.selectListIteratorByCondition(GenericDAO.java:1024)
	at org.ofbiz.core.entity.GenericDAO.selectByAnd(GenericDAO.java:595)
	at org.ofbiz.core.entity.GenericHelperDAO.findByAnd(GenericHelperDAO.java:134)
	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:792)
	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:777)
	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:754)
	at com.opensymphony.module.propertyset.ofbiz.OFBizPropertySet.getKeys(OFBizPropertySet.java:87)
	at com.opensymphony.module.propertyset.AbstractPropertySet.getKeys(AbstractPropertySet.java:292)
	at com.atlassian.jira.propertyset.PropertySetCache.bulkLoad(PropertySetCache.java:301)
	at com.atlassian.jira.propertyset.JiraCachingPropertySet.init(JiraCachingPropertySet.java:834)
	at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:45)
	at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:22)
	at com.atlassian.jira.config.properties.PropertiesManager.loadPropertySet(PropertiesManager.java:83)
	at com.atlassian.jira.config.properties.PropertiesManager.<init>(PropertiesManager.java:29)
	at com.atlassian.jira.config.properties.PropertiesManager.getInstance(PropertiesManager.java:39)
	at com.atlassian.jira.config.properties.ApplicationPropertiesImpl.getPropertiesManager(ApplicationPropertiesImpl.java:69)
	at com.atlassian.jira.config.properties.ApplicationPropertiesImpl.getString(ApplicationPropertiesImpl.java:117)
	at com.atlassian.jira.config.properties.ApplicationPropertiesImpl.getDefaultBackedString(ApplicationPropertiesImpl.java:143)
	at com.atlassian.jira.ComponentManager.registerExtensions(ComponentManager.java:299)
	at com.atlassian.jira.ComponentManager.initialise(ComponentManager.java:195)
	at com.atlassian.jira.ComponentManager.<init>(ComponentManager.java:181)
	at com.atlassian.jira.ComponentManager.<clinit>(ComponentManager.java:159)
	at com.atlassian.jira.upgrade.ConsistencyLauncher.launchConsistencyChecker(ConsistencyLauncher.java:63)
	at com.atlassian.jira.upgrade.ConsistencyLauncher.contextInitialized(ConsistencyLauncher.java:42)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:556)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:491)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:516)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.))
	at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
	at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:370)
	at org.objectweb.jotm.TraceTm.<clinit>(TraceTm.java:47)
	... 65 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)
	at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
	at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
	... 68 more
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.  You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.
	at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
	... 69 more
2010/01/04 13:18:33 org.apache.catalina.core.StandardContext listenerStart
致命的: クラス com.atlassian.jira.upgrade.UpgradeLauncher のリスナインスタンスにコンテキスト初期化イベントを送信中の例外です
java.lang.NoClassDefFoundError: Could not initialize class com.atlassian.jira.ComponentManager
	at com.atlassian.jira.upgrade.UpgradeLauncher.getJiraLicenseService(UpgradeLauncher.java:215)
	at com.atlassian.jira.upgrade.UpgradeLauncher.checkLicenseIsValid(UpgradeLauncher.java:145)
	at com.atlassian.jira.upgrade.UpgradeLauncher.checkIfUpgradeNeeded(UpgradeLauncher.java:85)
	at com.atlassian.jira.upgrade.UpgradeLauncher.contextInitialized(UpgradeLauncher.java:49)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:556)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:491)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:516)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
2010/01/04 13:18:33 org.apache.catalina.core.StandardContext listenerStart
致命的: クラス com.atlassian.jira.scheduler.JiraSchedulerLauncher のリスナインスタンスにコンテキスト初期化イベントを送信中の例外です
java.lang.NoClassDefFoundError: Could not initialize class com.atlassian.jira.ComponentManager
	at com.atlassian.jira.ManagerFactory.getApplicationProperties(ManagerFactory.java:200)
	at com.atlassian.jira.scheduler.JiraSchedulerLauncher.canCreateScheduler(JiraSchedulerLauncher.java:75)
	at com.atlassian.jira.scheduler.JiraSchedulerLauncher.proceedIfAllClear(JiraSchedulerLauncher.java:45)
	at com.atlassian.jira.scheduler.JiraSchedulerLauncher.contextInitialized(JiraSchedulerLauncher.java:29)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:556)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:491)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:516)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
2010/01/04 13:18:33 org.apache.catalina.core.StandardContext listenerStop
致命的: クラス com.atlassian.jira.startup.JiraStartupChecklistContextListener のリスナインスタンスにコンテキスト破棄イベントを送信中の例外です
java.lang.NoClassDefFoundError: Could not initialize class com.atlassian.jira.ComponentManager
	at com.atlassian.jira.startup.JiraStartupChecklistContextListener.unlockJiraHome(JiraStartupChecklistContextListener.java:75)
	at com.atlassian.jira.startup.JiraStartupChecklistContextListener.contextDestroyed(JiraStartupChecklistContextListener.java:62)
	at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3973)
	at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4577)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4474)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:556)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:491)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:516)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
]]> http://jfut.integ.jp/2010/01/04/jira4-and-new-plugin-infrastructure/feed/ 2 WP FreeStyle Wiki 0.1 http://jfut.integ.jp/2010/01/01/wp-fswiki/ http://jfut.integ.jp/2010/01/01/wp-fswiki/#comments Thu, 31 Dec 2009 17:00:47 +0000 jfut http://jfut.integ.jp/?p=686

tDiaryからWordPressに乗り換え、これから書いていくのに標準のエディタで書くのがどうしても面倒だったので、一番慣れ親しんでいるFreeStyle Wikiの記法で書けるPlugin、WP FreeStyle Wikiを作りました。作ったといってもかなりの強引なことをしていてFreeStyle Wikiを丸ごと中で持っており、そこへ外部コマンドで投げてレンダリングしているだけです。

これは、大晦日の31日にWordPress Pluginをなんとなく見ていたところ、makotokwさん(ありがとうございます！)が作られているPukiWiki for WordPressというPluginを見つけて、ソースを見てみたらPukiWikiを丸ごと中に持っていてそんな手があったかと、そのまま勢いで年が明ける前にFreeStyle Wiki用に改造したものです。

以下に置いてありますので使いたい方がいましたらご自由にお使いください。ライセンスは中に持っているFreeStyle Wikiと同じGPLです。

記法サンプル

以下、記法のサンプルです。 [fswiki] と [/fswiki] で囲んだ部分がFreeStyle Wikiで処理されます。

ソース

[fswiki]
!!見出し

行を!ではじめると見出しになります。
見出しは3レベルありますが、!!!は記事名と被るので使わない方が良いかもしれません。

!!中見出し
!小見出し

!!テキスト装飾

シングルクォート2つで囲むと''イタリック''になります。
シングルクォート3つで囲むと'''ボールド'''になります。
これは==打ち消し線==です。
これは__下線__です。

!!引用

""これは引用です。
""これも引用です。

!!説明

:項目:説明文

::項目
:::説明文は複数行にわけて書くこともできます。
:::こんな感じで。

!!項目

行を*ではじめるとリストになります。
リストは*の個数に応じて3段階までネストすることができます。

*項目1-1
**項目2-1
**項目2-2
***項目3-1
*項目1-2
**項目2-3

行を+ではじめると番号付きリストになります。

+番号付き項目1
++番号付き項目1-1
+番号付き項目2
+番号付き項目3

!!リンク

*http://www.yahoo.co.jp/
*[Google|http://www.google.co.jp/]

!!テーブル

CSVはテーブルになります。1行目がヘッダになります。

,1-1,1-2,1-3
,2-1,2-2,2-3

セル内にカンマを含めたい場合は値をダブルクォートで囲みます。
また、ダブルクォートで囲んだセルにダブルクォートを表示したい場合はダブルクォートを2つ続けて記述します。

,カンマ,ダブルクォート
,"セルの中にカンマ,を表示","セルの中にダブルクォート""を表示"

!!整形済テキスト

行頭をスペースまたはタブではじめると整形済テキストとして扱われます。

これは整形済テキストです。
入力したとおりに表示されます。

{{pre
preタグバージョン
これは整形済テキストです。
入力したとおりに表示されます。
}}

!!水平線

行頭に----と書くと水平線になります。

----

!!コメント

行を//ではじめるとその行はコメントとみなされます。コメント行は一切出力されません。

//これはコメントになります。画面には出力されません。
[/fswiki]

レンダリング結果

上記のソースが下記のようになります。

見出し

行を!ではじめると見出しになります。見出しは3レベルありますが、!!!は記事名と被るので使わない方が良いかもしれません。

中見出し

小見出し

テキスト装飾

シングルクォート2つで囲むとイタリックになります。シングルクォート3つで囲むとボールドになります。これは打ち消し線です。これは下線です。

引用

これは引用です。

これも引用です。

説明

項目
説明文
項目
説明文は複数行にわけて書くこともできます。こんな感じで。

項目

行を*ではじめるとリストになります。リストは*の個数に応じて3段階までネストすることができます。

  • 項目1-1
    • 項目2-1
    • 項目2-2
      • 項目3-1
  • 項目1-2
    • 項目2-3

行を+ではじめると番号付きリストになります。

  1. 番号付き項目1
    1. 番号付き項目1-1
  2. 番号付き項目2
  3. 番号付き項目3

リンク

テーブル

CSVはテーブルになります。1行目がヘッダになります。

1-1 1-2 1-3
2-1 2-2 2-3

セル内にカンマを含めたい場合は値をダブルクォートで囲みます。また、ダブルクォートで囲んだセルにダブルクォートを表示したい場合はダブルクォートを2つ続けて記述します。

カンマ ダブルクォート
セルの中にカンマ,を表示 セルの中にダブルクォート"を表示

整形済テキスト

行頭をスペースまたはタブではじめると整形済テキストとして扱われます。

これは整形済テキストです。入力したとおりに表示されます。

preタグバージョン
これは整形済テキストです。
入力したとおりに表示されます。

水平線

行頭に—-と書くと水平線になります。

コメント

行を//ではじめるとその行はコメントとみなされます。コメント行は一切出力されません。

]]> http://jfut.integ.jp/2010/01/01/wp-fswiki/feed/ 2 tDiaryからWordPressへ http://jfut.integ.jp/2010/01/01/tdiary-to-wordpress/ http://jfut.integ.jp/2010/01/01/tdiary-to-wordpress/#comments Thu, 31 Dec 2009 15:59:54 +0000 jfut http://jfut.integ.jp/?p=682

新年を向かえtDiaryからWordPressへ乗り換えました。

最近WordPressで何かすることが多いので自分のところもWordPressにしました。tDiaryではWikiスタイル + 適当な書き方で書いていたので、自分の書き方に併せて移行するスクリプトを書きました。移行漏れなどまだ一部不具合があるかもしれませんがちょくちょく直していきます。

]]> http://jfut.integ.jp/2010/01/01/tdiary-to-wordpress/feed/ 0 あけましておめでとうございます http://jfut.integ.jp/2010/01/01/happy-new-year/ http://jfut.integ.jp/2010/01/01/happy-new-year/#comments Thu, 31 Dec 2009 15:56:19 +0000 jfut http://jfut.integ.jp/?p=680

本年もどうぞよろしくお願い申し上げますm(_ _)m。

]]> http://jfut.integ.jp/2010/01/01/happy-new-year/feed/ 0 DellのサーバマシンのBIOS設定をLinux上から行う方法 http://jfut.integ.jp/2009/11/12/dell-bios-on-linux/ http://jfut.integ.jp/2009/11/12/dell-bios-on-linux/#comments Thu, 12 Nov 2009 03:00:01 +0000 jfut http://jfuttest1.integ.jp/2009/11/dell%e3%81%ae%e3%82%b5%e3%83%bc%e3%83%90%e3%83%9e%e3%82%b7%e3%83%b3%e3%81%aebios%e8%a8%ad%e5%ae%9a%e3%82%92linux%e4%b8%8a%e3%81%8b%e3%82%89%e8%a1%8c%e3%81%86%e6%96%b9%e6%b3%95/
  • 要約: activateCmosToken 0xXXXX でDellのサーバマシンのBIOS設定は変えられます (但し、サポート外)

既に CentOS 5.x をインストール済みの Dell PowerEdge 830 サーバで、OS上でメモリがなぜか256MBしか認識されていませんでした。何か壊れてるのかと思い、既にインストールしてあったDell提供のサーバ管理ソフトウェア OpenManage でハードウェア情報を確認してみると、1GBのメモリが2枚認識されており、合計2GBと表示されていました。

そこで調べてみるとDellのサーバマシンのBIOSには、巨大なメモリが見えるとインストールが失敗するようなOSインストール用に OS Install Mode という設定があり、これが Enable になっているとメモリが256MBしか見えないようにハード的に制約を加えるようです。

というわけで、BIOSの設定を変えれば良いことが判りました。でも、このサーバは遠隔地に置いてあって、現地に行くのがちょっと大変です。こういう時にリモートKVMが使える別売りのDell Remote Access Controller(DRAC)が入っていれば、BIOS画面を直に見ながら簡単に設定できるのですが、残念ながらこのマシンにはDRACは入っていませんでした。というわけで、Linux上からBIOSの設定を変えられないのかなと調べたら変えられました。方法としては次の2つあります。

  1. OpenManage 上のBIOS設定で変更
  2. smbios に含まれるコマンドで変更

1は、WEB UIから設定する方法ですが、設定できる項目に限りがありました。基本的な項目以外は設定できないと思って良いでしょう。今回設定を変えたかった OS Install Mode も設定できませんでした。以下に、PowerEdge 830 で設定可能な項目と設定されていた値を記しておきます。

  • 一般
    • Num Lock: オン
    • Diskette: 自動
    • NIC: PXE で有効
    • USB: BIOS サポートありで有効
    • IDE: 自動
    • Boot Sequence: デバイスリスト
    • Speaker: オン
    • CPU Logical Processor (HyperThreading): 有効
    • AC Power Recovery Mode: 最終
    • Embedded SATA Controller: ATA
    • SATA Port 0: 自動
    • SATA Port 1: 自動
    • SATA Port 2: オフ
    • SATA Port 3: オフ
    • IDE Primary Drive 0: 自動
    • IDE Primary Drive 1: オフ
    • Demand-Based Power Management: 無効
  • シリアル通信
    • Serial Port 1: 不明
    • Console Redirection After Boot: 有効
    • Console Redirection: シリアルポート 1
    • Console Redirection Failsafe BAUD Rate: 19200

OpenManage はyumで簡単にインストールできるので、上記で設定した項目があれば、OpenManage で設定するのが良いと思います。

2は、コマンドラインから設定する方法です。smbios と libsmbios は、OpenManage を入れると一緒にインストールされるDellのサーバマシンのBIOSにアクセスするためのユーティリティ群です。

こちらはおそらくDellのサーバマシンに用意されているBIOSの設定項目すべてを設定できるのだと思います。ただし、BIOSの設定を変える activateCmosToken というコマンドは Unsupported Binaries に分類されています。従って、この記事を読んで設定したらBIOSが壊れてマシンが起動しなくなることもあるかもしれません。そうなっても自分で責任とれる方以外は絶対に行わない方が良いでしょう。

というわけで、設定の仕方です。設定を行うのはactivateCmosToken コマンドを使います。基本構文は次のとおりです。

# /usr/sbin/activateCmosToken 0x"Token Value"

Token Valueというのは、BIOS設定の項目とというる値に対してユニークに割り振られている値になります。Token Valueの一覧は以下にあります。先頭の項目がToken Valueになります。

見てみれば判りますが、よくあるBIOS設定項目、最新の技術に関する設定項目、そして、Dell独自の設定項目があります。

現在の値を確認するには、isCmosTokenActive コマンドを使います。activateCmosToken 同様、引数に 0x"Token Value" を取ればいいだけです。出力の BITFIELD が 1 の場合、それが有効になっているという意味です。

では具体的に OS Install Mode を設定を変え、設定が変わっているか確認します。Token Value List より、OS Install Mode のとりうる値は Enable と Disable の2つで、それぞれに 0×008a と 0×008b の Token Value が割り当てられています。片方の Token Value に対して activateCmosToken を実行すると、もう片方の Token Value の BITFIELD が無効を示す 0 に自動的に変わります。

  • Limit System Memory (OS Install Mode) を無効化する方法
# /usr/sbin/activateCmosToken 0x008b
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 0
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
  • Limit System Memory (OS Install Mode) 有効化する方法
# /usr/sbin/activateCmosToken 0x008a
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 0

以上です。設定はマシンを再起動すると反映されます。

実際に上記の OS Install Mode を無効化する方法で実際に設定しました。その結果、次のように正常にメモリ2GB認識されるようになりました。

  • 設定前
# free
             total       used       free     shared    buffers     cached
Mem:        252164     232364      19800          0       9264     129620
-/+ buffers/cache:      93480     158684
Swap:      2097144        236    2096908
  • 設定後
# free
             total       used       free     shared    buffers     cached
Mem:       2059368     220968    1838400          0      10396     134724
-/+ buffers/cache:      75848    1983520
Swap:      2097144          0    2097144

無事、サーバのある現地に行くことなく、BIOS設定を変えることができました。遠隔地にあるサーバマシンのBIOS設定をどうしてもリモートで変えたい場合は、試してみると良いかもしれません。ただし、サポート外の方法ですので、BIOSが壊れて起動しなくなるかもしれないことは覚えておいてくださいね！

]]> http://jfut.integ.jp/2009/11/12/dell-bios-on-linux/feed/ 0 仮想化環境をテストする環境 http://jfut.integ.jp/2009/11/04/%e4%bb%ae%e6%83%b3%e5%8c%96%e7%92%b0%e5%a2%83%e3%82%92%e3%83%86%e3%82%b9%e3%83%88%e3%81%99%e3%82%8b%e7%92%b0%e5%a2%83/ http://jfut.integ.jp/2009/11/04/%e4%bb%ae%e6%83%b3%e5%8c%96%e7%92%b0%e5%a2%83%e3%82%92%e3%83%86%e3%82%b9%e3%83%88%e3%81%99%e3%82%8b%e7%92%b0%e5%a2%83/#comments Wed, 04 Nov 2009 03:00:01 +0000 jfut http://jfuttest1.integ.jp/2009/11/%e4%bb%ae%e6%83%b3%e5%8c%96%e7%92%b0%e5%a2%83%e3%82%92%e3%83%86%e3%82%b9%e3%83%88%e3%81%99%e3%82%8b%e7%92%b0%e5%a2%83/

最近XenとKVMのHVM環境を比較して試していますが、これまで1台のマシン環境を毎回壊して作り直していました。これが毎回面倒なため、現在、他の用途だったマシンを2台潰して再構築しています。

仮想化環境をテストするのに、PVM環境をテストするなら適当な仮想化環境上(例: VMwareの上でXen PVM環境)で問題ないものの、HVM環境をテストするにはVT対応のCPUが載った実機が必要になるので面倒です。最近のCPUでないとVT対応していないし、VMをたくさん動かすにはメモリもたくさん必要で、そこらへんに余ってる古いマシンで試せず困りものです。

最終的にあと2台用意してXenとKVMを2ノードづつ計4台の環境にしたいものの残り2台をどうしようかな。

]]> http://jfut.integ.jp/2009/11/04/%e4%bb%ae%e6%83%b3%e5%8c%96%e7%92%b0%e5%a2%83%e3%82%92%e3%83%86%e3%82%b9%e3%83%88%e3%81%99%e3%82%8b%e7%92%b0%e5%a2%83/feed/ 0 XenからKVMへ、ファイルからLVMへ http://jfut.integ.jp/2009/10/30/xen%e3%81%8b%e3%82%89kvm%e3%81%b8%e3%80%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%8b%e3%82%89lvm%e3%81%b8/ http://jfut.integ.jp/2009/10/30/xen%e3%81%8b%e3%82%89kvm%e3%81%b8%e3%80%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%8b%e3%82%89lvm%e3%81%b8/#comments Fri, 30 Oct 2009 03:00:01 +0000 jfut http://jfuttest1.integ.jp/2009/10/xen%e3%81%8b%e3%82%89kvm%e3%81%b8%e3%80%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%8b%e3%82%89lvm%e3%81%b8/

この日記が動いてるサーバはまだXenですが、新しく仮想マシンをたくさん作る機会があったので、XenからKVMに乗り換えました。OSはdebootstrapになっていますが、virt-installで強引なことしているのでDebianじゃなくてCentOSに入れ替わっています。

# gnt-instance list
Instance           Hypervisor OS          Primary_node    Status     Memory
admin1.example.org   kvm        debootstrap node1.example.org running      1.0G
admin2.example.org   kvm        debootstrap node2.example.org running      1.0G
cron1.example.org    kvm        debootstrap node1.example.org running      1.0G
db1.example.org      kvm        debootstrap node1.example.org running      1.0G
ftp1.example.org     kvm        debootstrap node2.example.org running      512M
irc1.example.org     kvm        debootstrap node1.example.org running      512M
lvs1.example.org     kvm        debootstrap node2.example.org running      512M
lvs2.example.org     kvm        debootstrap node1.example.org running      512M
mail1.example.org    kvm        debootstrap node1.example.org running      1.0G
mail2.example.org    kvm        debootstrap node2.example.org running      1.0G
nouse.example.org    kvm        debootstrap node2.example.org ADMIN_down      -
template.example.org kvm        debootstrap node1.example.org ADMIN_down      -
web1.example.org     kvm        debootstrap node2.example.org running      1.0G
web-ssl1.example.org kvm        debootstrap node1.example.org running      1.0G
web-ssl2.example.org kvm        debootstrap node2.example.org running      1.0G

ディスクイメージもファイルからLVMへ乗り換えました。I/O的にも早くなりましたし、1仮想マシンに1LV割り当てたのでライブマイグレーションも出来るようになりました。

# cat /proc/drbd
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by mockbuild@v20z-x86-64.home.local, 2009-08-29 14:07:55

 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:1030228 nr:0 dw:1030228 dr:515856 al:499 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 2: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:684592 dw:684592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:282556 nr:0 dw:282556 dr:432780 al:226 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 4: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:594628 dw:594628 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 5: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281224 nr:0 dw:281224 dr:433112 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 6: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281116 dw:281116 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 7: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281048 nr:0 dw:281048 dr:432008 al:227 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 8: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:283900 dw:283900 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 9: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:286256 nr:0 dw:286256 dr:430084 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
10: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281384 dw:281384 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
11: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:306608 nr:0 dw:306608 dr:532548 al:286 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

13: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:681680 nr:0 dw:681680 dr:823276 al:468 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
14: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:571076 dw:571076 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

100: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:48640 nr:0 dw:48640 dr:217 al:23 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
101: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:188

今回KVMを使ってみて、XenとKVMでは、ホストマシン上でのCPU(uptime)とメモリ(free)の表示が違っていることに気付きました。

Xenを使った時のuptimeの表示は、ホスト側も特殊なDom0 Kernelなのでゲスト側でCPUに負荷が掛かってもホスト側のuptimeにその負荷具合が反映されませんでした。一方、KVMの場合はゲストマシンは1プロセスとして見えるので、ゲスト側に負荷を与えるとホスト側のuptimeの表示に負荷具合が反映されました。

Xenを使った時のfreeの表示は、dom_mem0を指定していない場合、割り当てたメモリ分だけtotalの値が減り、ホスト側では見えなくなります。一方、KVMの場合は起動時に指定したメモリを上限とし、実際にゲスト上でメモリが使用されるとホスト側のfreeが消費されてusedが増えていき、totalの値は常に物理メモリの量のままでした。つまり常に動的なバルーン機能が働いているような状態。もしくは、Sparseファイルのメモリ版のような状態。

どちらが良いかは好みですが、ホスト側で状況を把握できるKVMの方が良い気がしています。あと、最近はXenよりKVMが推されているようなので今後はXenとKVMどちらでも良い場合はKVMを使っていこうと思っています。

]]> http://jfut.integ.jp/2009/10/30/xen%e3%81%8b%e3%82%89kvm%e3%81%b8%e3%80%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%8b%e3%82%89lvm%e3%81%b8/feed/ 0