java.lang.NoClassDefFoundError JaxbAnnotationIntrospector

はまり

[GLASSFISH-21141] Missing jackson-module-jaxb-annotations JAR causes error on first Jersey/Jackson JSON response - Java.net JIRA

A quick hack how I managed to overcome this on GlassFish Server Open Source Edition 4.1 (build 13):
0) stopped the server
1) downloaded and copied the jars below into glassfish4\glassfish\modules (version: 2.4.2 for all)
jackson-annotations.jar
jackson-core.jar
jackson-databind.jar
jackson-jaxrs-base.jar
jackson-jaxrs-json-provider.jar
jackson-module-jaxb-annotations.jar
2) deleted the osgi-cache: removed glassfish4\glassfish\domains\domain1\osgi-cache\felix
3) re-started the server

分散的にsqliteを扱う場合のパフォーマンスに関するメモ

巨大なSQLliteのDBをいくつかのDBに分けた場合のパフォーマンスに関するメモ。

結論:2つ以上のDBに交互にSELECT文を発行すると、そうでない場合に比べて10〜100倍くらい遅くなった。


最初に複数のDBコネクションを配列に入れる。

my @dbhs = qw();
for(my $take=$TAKE_MIN; $take<=$TAKE_MAX; $take++){
    my $path = sprintf($DB_PATH2, $take);
    my $data_source2 = "dbi:SQLite:dbname=$path";
    my $dbh2 = DBI->connect($data_source2);
    push(@dbhs, $dbh2);
}

で、SELECT文を各DBに交互に発行。

    my $sql2 = "SELECT * FROM tb WHERE uid=? LIMIT 1";
    for(my $take=$TAKE_MIN; $take<=$TAKE_MAX; $take++){
        my $rows2 = $dbhs[$take-1]->selectall_arrayref($sql2, { Slice => {} }, $uid);
        for my $row2 (@$rows2){
            my $uid2 = $row2->{uid};
        }
    }

1つのDBだけに比べて2つ以上の場合は、HDDのガリガリ音も激しく、またdstatでdiskのread/write両方ほとんど数値がでていなかったので、HDDのヘッドが激しく動きまくってそこがボトルネックになっているのではないかと予想。

同じクラス名は避けるべし

重大: Mapping conflict. A Servlet registration exists with same mapping as the Jersey servlet application, named jp.unko.hoge1.resources.MyApplication, at the servlet mapping, /rest/*. The Jersey servlet is not deployed.
重大: Mapping conflict. A Servlet registration exists with same mapping as the Jersey servlet application, named jp.unko.hoge2.resources.MyApplication, at the servlet mapping, /rest/*. The Jersey servlet is not deployed.

hoge1アプリケーションからhoge2の.jarに依存を張っていて、その両方に同じクラス名のクラスがあるとまずいっぽい。
あ クラス名ってより@Pathか

JAVAでSQLiteを使う(glassfish)

WEBサービスで使う機械学習のモデルを実現するためにJAVAのヒープを使うっていう話もあったが、
メモリに頼ったやり方だとモデルが巨大化していった時にスケールしにくいし、ユーザ0のうちから金がかかるのは微妙。
なので、SQLite+ヒープのキャッシュで賄う方向性について模索中。


■ 環境構築
glassfishを使う場合、管理コンソールでの特別な設定は不要。
たぶんあれはプールしたいときに必要。でも、たしかどっかの記事でSQLiteではコネクションをPoolする意味ないみたいなのを読んだ気がする。

jarはここから最新のを落として、
xerial / sqlite-jdbc / Downloads — Bitbucket
以下の3箇所に配置。たぶん全部は必要ない。おいたらGlassfishのdomain再起動が必要。
・src/lib/以下
・略glassfish-4.1/glassfish/lib/
・略glassfish-4.1/glassfish/domains/domain1/lib/
古いjarバージョンだと、readonlyモードに切り替えられなくてハマった。
それと、複数の異なるバージョンを同じディレクトリに置かないほうがいい。


pom.xml

<dependency>
            <groupId>sqlite-jdbc-3.8.10.1.jar</groupId>
            <artifactId>sqlite-jdbc-3.8.10.1.jar</artifactId>
            <version>3.8.10.1</version>
            <scope>system</scope>
            <systemPath>${basedir}/src/lib/sqlite-jdbc-3.8.10.1.jar</systemPath>
        </dependency>

■ 実験
main.java

            Class.forName("org.sqlite.JDBC");
            SQLiteConfig config = new SQLiteConfig();
            config.setReadOnly(true);
            conn = DriverManager.getConnection("jdbc:SQLite:" + DB_PATH, config.toProperties());
            // check
            System.out.println("readonly:" + conn.isReadOnly());

            // test
            //...時間のかかるSQL文

同時に読み込みできるかtest

ab -n 2 -c 2 http://localhost:8080/TEST/rest/test

readOnlyモードが無効だった時はコンソールに「[SQLITE_BUSY] The database file is locked (database is locked) 」がでていたが、うまくいくと2つ以上のアクセスを同時にさばくことができた。



ーー
次に1つのスレッドがINSERTする中で、複数のREAD ONLYな処理を捌けるのかを確かめてみる.
非ReadOnlyモードで1秒間に2回INSERTを行い続ける中で、別のスレッドで数十秒レベルのSELECTをReadOnlyモードで行い続けた。
その結果、SELECT文の時間が1.5倍くらいになったものの、ロックエラーはでることはなくなった。

最大使用メモリの取得


参考:GNU timeでプロセスの最大メモリ使用量を取得するシェルスクリプトを書いてみた - N_Nao’s log


mac

/usr/bin/time -lp perl myScript.pl

maximum resident set sizeが最大使用メモリらしい

real 172.55
user 144.37
sys 20.92
12747128832 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
7352383 page reclaims
3 page faults
0 swaps
22 block input operations
2 block output operations
120 messages sent
121 messages received
0 signals received
215 voluntary context switches
113544 involuntary context switches