PDF文書からテキストを取り出す必要があって、Nutchでも使用されていることだし、PDFBoxというJavaのオープンソースを使うことにしました。

使い方は簡単で、読み取りたい文書のInputStreamやFileオブジェクトを渡してPDDocumentというオブジェクトを作ったら、後はPDFTextStripperというクラスのgetTextというメソッドにPDDocumentを渡すだけです。

ところが、やってみると、日本語の文書ではちっともテキストを出してくれません。

どうも、日本語のエンコーディングを諦めて何にも処理してくれていない風情でした。そもそもPDFのエンコーディングの決定方法とかも知らなかったのですが、日本語などはフォントに対するCMapというものでエンコーディングが決まるとか(ここら辺りは、PDFLibという商用ライブラリのマニュアルの4.7章で解説されていました。http://www.pdflib.com/jp/pdffiles/PDFlib-manual-J.pdf )。

で、PDFBoxでは、PDFontというクラスのstaticなcmapSubstitutionというMap型のフィールドでCMapを保持するみたいなのですが、日本語関係のCMapは一切、セットされていません。CMapそのものは、PDFBoxの配布の中の/Resource/cmapに一揃い用意されているのに。

ということで、半信半疑なままPDFontの中で日本語用のCMapもセットするようにしてみると、無事、テキストが出力されました。ひとまずは、めでたし。でも、試した日本語PDF文書は２つだけなので、幅広く大丈夫なのかは不明瞭なんですが。

とある必要があって、MS-Word文書のテキストを抽出するために、Jakarta POIを使いました。

Word文書を処理するためのライブラリとして、POIの中にHWPFというサブプロジェクトがあるものの、正式リリースされておらず、おまけに開発も停止しているみたいなので、若干の不安を覚えつつも、他にこれという選択肢もないための消去法的な採用です。

でも、単体テストでは特に問題なく、テキストを抽出できました。めでたい。

ということで、どんな文書が存在するのか把握していないディレクトリの中を対象として、まとめてガサーっと処理してみると、最後の文書まで辿り着く前に、JVMのheapが足りないとOutOfMemoryErrorが発生してしまいます。何度やっても発生します。調べていくと、パスワード保護されている文書の処理で発生していることがわかりました。

HWPFのHWPFDocumentオブジェクトのコンストラクター内で呼ばれている、POIFSパッケージのクラスで問題が起こっているところまでは追跡しましたが、現時点で、最終的に犯人を補足できていません。というか、この時点で自ら捜査することに疲れ、世の中の誰かが既に名推理を発表していないか、探すことにしたのですが、それも見つけ出せていません。

さあ、この難事件の結末や如何に？ 解決編を待て。

(解決するのだろうか。どこかに名探偵がいて、この中に犯人がいる、とかズバっと言って欲しいです)

ちょっと重くてUI不要な処理を、複数のPCで同時に実行させたい、と考えたのが、今回の事件の発端でした。

複数で同時に実行と言っても、それぞれ独立した処理の単位でおまけに協調動作も不要なので、グリッドコンピューティングとかP2Pとかそんな洗練されたシロモノではありません。要は、複数の処理の実行依頼を発行するClient役と、その依頼を待機して処理を実行するServer役を作ればいいのです。
で、流暢ではないし、かなり訛っているかもしれませんが、何とか読み書きできる唯一の言語なので、いつもの通り、Javaで書くことにしました。JVMを超えて起動する方法にはRMIとかもあるのでしょうが、EJBコンテナとかは使わずに済ませたいので、単純にネットワークプログラミングすることにしました。さらに、実行する処理は重くってトロいはずなので、Server役では、処理受付と処理実行のスレッドを分けようとか、生意気にも考えてみました。
そう構想しただけで、プログラミング初級者の私には緊張感が走ります。だって、ネットワーク、マルチスレッド、ですよ！ 高橋麻奈著「やさしいJava」の表紙を開いたのはつい昨日のことのようなのに、随分と遠くまで来たものだなあ、とここまでの軌跡を振り返りたくもなるというものです。

さて、そんな感慨はともかく。

ネットワークプログラミングとかいいながら、できるだけ高レベルなAPIで済ませたいと考えるのが怠け者の習性です。でも、適当なライブラリを探し出したり、その使い方を習得したり、それなりに大変です。もしかしたら、怠け者の習性、ではなくて、自分の腕に自信のない者の習性かもしれません。腕に覚えがあれば、さっさと自分で必要なものを作ればいいのですから。
さて、そんな繰言はともかく。

なにしろ、怠け者で自信のない私は、Apache MINAを使うことにしたのです。
MINAでは、ネットワークイベントのハンドラーを作成し、MINAが提供するServiceオブジェクト(呼び出される側)やIoConnectionオブジェクト(呼び出す側)にハンドラーをバインドすることによって、後はイベントドリブン的にMINAが面倒見てくれます。特に本来的な連携内容は、serializableなオブジェクトをIoSessionという通信オブジェクトへのwriteとrecieveイベントを通して実現することとなります。なので、本来のビジネスロジックをネットワークの低レベルな処理とは独立した形で実装し易いらしいのです。
ずいぶんと簡単そうです、簡単なはずだったのですが...結構、試行錯誤してしまいました。最大の陥穽は、sessionCreateの後に連続して起こるように説明されていたsessionOpenというイベントが起こらず、どこで最初のメッセージ用のオブジェクトを書き込めばいいかわからなかったことでした。結果的に、イベントハンドラ内ではなく、IoConnectionを作成する呼出側の主役で、IoSessionを取得してそのままメッセージをwriteすればよかったのでした。

それはそうと、今回の作業の前に大急ぎで、結城浩著「Java言語で学ぶデザインパターン入門 マルチスレッド編」を読みました。マルチスレッドという迷宮に踏み込む際の護符とか呪文を手に入れるようなつもりで。
実際の今回のプログラミングは、デザインパターンを意識する程のレベルではありませんでした。ただ、MINAのクラスの中でconnectFutureとかwriteFutureとかあって使うことになった際に、お、これはFutureパターンなんだな、とか把握できて、呪文もまんざら捨てたものではなかったのでした。
やっぱり、先人の知恵は重要だし、共通理解のためのイディオムの習得は大切なんだなと思えた、ちょっと教訓めいた話でした(!?)

しばらく前から、Hyper Estraierを全文検索エンジンとして、その上にアプリケーションを作ってみているのですが、その過程で感じたことなど。

[ 嬉しいこと・感心すること ]

(1)  作者の平林さんが優秀かつ仕事が素早い。
Version Upの頻度やMLでの回答の速さは感心するほかありません。もちろん、アイディアや知識も豊富だということにも、ホント感心します。
今日もMLに出した質問に対して、30分後には回答を返してくれていました。
属性条件(例えばタイトルとか、普通のキーワードとは別に管理されている特定の属性についての条件です)をつけた検索で検索結果件数が変動する現象は、性能とのトレードオフで、キーワード検索で絞り込まれた候補文書全ての属性を照合するのではなく、照合結果が要求された件数に達すると残りの合致件数は予測しているそうです。そんなことまでやってるのですよ、Hyper Estraierは。それとも全文検索エンジンでは、普通のことなのでしょうか？ 因みに、Googleでも同様の現象があるそうです。ということも平林さんの回答で初めて知りました。
なんだか、自分の無知さ加減が恥ずかしくなります。

(2) INDEXを分散させることができる。メタ検索ができる。
細かい点はともかく、INDEXの分散はとても分かり易い特徴で、また、スケーラビリティへの期待を抱かせられるところです。
単に、スケールのためだけでなく、Indexing対象の性質や分類などでINDEXを分別する仕組みをアプリケーションで考慮できるので、色々なことを画策できそうな気にもなります。
しかも、INDEXの分散、メタ検索を利用するために、Hyper Estraier側でHTTPプロトコルのネットワークサービスを装備してくれていて、尚且つシンプルなノードAPIという便利な利用方法が提供されています。

[ 悲しいこと・困ったこと ]

(1) 自分の無知さと仕事の遅さを再確認させられる。
何だか、自分でアプリケーション作っていても、その内、Hyper Estraierに同等以上の機能が実装されるような気もしますし。

(2) ノードAPIのメタ検索の性能的な不安を払拭できない。
さて、これが目下、微妙に気掛かりなところです。
検索結果が大量となるようなことはよくありがちです。何千件、何万件の結果がある検索の場合、当然、全件についての詳細な情報を取得するのは性能的に厳しいことですし、第一、せっかく取得しても利用者が人間の場合にはそんな大量の情報は利用できないので、無駄です。なので、普通は、せいぜい数十件分を1ページ分としてとりあえず返すことになります。でも、利用者が他のページも見たいと思った場合には、対象ページに遷移する必要があります。そうすると、そのページ分の数十件分の情報をまた取得する必要があります。
例えば1ページ当たり10件ずつ表示するとすれば、1ページ目は1件目から10件目の情報を、2ページ目は11件目から20件目の情報を、100ページ目は991件目から1000件目の情報を取得すればいい訳です。
ところが、これまでノードAPIでは、検索結果のn件目からm件分の情報を貰うということができなかったのでした。ですが、最新リリースの1.1.3では、skipパラメータというものが導入されて、このような要望が叶えられました！嬉しいことです。
ところがところが、メタ検索では、最終的なスコア順が個々のノードでの検索では決定できないので、n件目からという限定した検索はできないらしいのです。そう言われれば、確かにそうなのですが...でも、そうなると、メタ検索では、100ページ目の情報を得るためには、991件目からの10件分ではなく、1件目から1000件分の情報を取得する他ないことになるので、ちょっと、不安になる訳です。
多分、snippetを作成したりする処理はコストが大きいのではないかと思うので、ノードAPIで、文書IDとURIだけを返す検索メソッドを提供して貰って、1ページ分だけを改めてアプリケーションからノードAPIへ依頼するとかの方法が必要なのかもしれないとも思ったり。

あれ？ もしかして、メタ検索内で既に、候補取得のためのミニマルな検索(文書IDのみの結果)＋最終結果のための一般の検索(snippetなども含めた結果)という方法で実装されていりするのかもしれません。
早速、明日、動作確認してみねば。それより、MLで聞いた方が早いのかなあ!?

いえ、残念ながら、P2PとかC/SとかASPとかの話ではありません。単に未熟なプログラマーの悩みのお話です。

手法はなんでもいいのですが、例えばDIなどでプログラムをできるだけ疎結合にして部品の独立性を高める方が、利用の際まで自由度を担保できるはずです。また、例えばなんらかの定数などをプログラム内に保持するよりも、外部に保持させて変更を容易にする方が、利用の自由度、柔軟性は高まるはずです。
束縛を少なくして自由度を高めることは、やっぱりいいことのように思えます。

一方で、部品の独立性が高まると、私のような未熟者あるいは記憶力や注意力が弱い者にとっては、複数の部品が連携して実現される一連の処理のシーケンスを、きちんとトレースすることが難しくなってしまいます。
それよりも一層、深刻なのが、プログラム外で設定された事項が関係すると、途端にコンパイルチェックという庇護から外れ、実行時チェックだけの、プログラミング時には自己責任でチェックするしかない、実に厳しい世界に放り出されることです。

自由と束縛のバランスをどこに置くべきなのか、どこまで庇護を求めるべきか、自分なりの価値観を確立できていないせいで、戸惑ったりするわけです。
悟りを開かれた導師たちはどうなんだろう？

さあ、プロファイリングするぞーっ的に力を入れなくても、必要な時にサクッとパフォーマンス分析のための情報が採取できればいいな、と思ったことが発端でした。

Webアプリケーションについて、開発環境内で開発ツールでではなく、運用システムで必要に応じて情報を採取したいと思ったのです。で、アプリケーションサーバーにそれ風の機能があっても不思議はないよなあ、と思ったら、WebSphereにはTivoliのツールが統合されているらしいではないですか。でもそれは、EJBコンテナとして利用していれば色々と有用そうな情報が採取できそうなのですが、ServletとPOJOについてはほとんど採取できるデータはなさそうです。

そこで、InfraREDというオープンソースのツールを使ってみることにしました。
InfraREDはAOPを利用したパフォーマンスモニタと謳われています。ドキュメントに記載されている特長には、確かにAOPが貢献しているいるようです。曰く、コーディング不要、APIレベルでの詳細化が可能、JDBCとかSQLの詳細情報も取れる、オーバーヘッドが小さくて実運用システムで利用できる、etc.

ドキュメントを読むとどうやら、InfraREDは、各種のメトリクスを採取するアドバイスを対象アプリケーションにweaveするアスペクトが定義されたAOPによって、パフォーマンスデータを採取するようです。なるほど、コーディングしないでPOJOのメソッドに関連づけてメトリクス採取の処理を実行するということを考えれば、AOPは理に適っているように思えます。
と言いながら、実は私はAOPなんて使ったこともなければよくわかってもいないんですが、
http://www-06.ibm.com/jp/developerworks/java/060405/j_j-jip.shtml で、まんまプロファイラにはAOPが有効だ、ついては自分で作るのもお勧めだみたいなことが書かれていました。

自分で作らなくても既に立派なものがあれば活用したいということで、やっぱりこの際、InfraREDな訳です。
InfraREDでは、AspectJもしくはAspectWerkzを内部的に利用しています。付け焼刃的にAOPについて情報収集した感じでは、AspectJがJavaのコードでアスペクトを記述してコンパイルすることでアスペクトをpointcutにweaveする(編みこむ)アプローチであるのに対して、AspectWerkzはxmlでアスペクトを記述してクラスローディングの際にweaveすることが可能らしいです。
InfraREDは、デフォルトでよければ自らアスペクトを定義する必要はないようですが、一応、今後の柔軟性を考慮して、AspectWerkzの方を利用することにします(どちらを利用するかによって、インストール作業が異なります)。

さて、インストール作業を行って動かしてみると......HTTPリクエストレベルの情報しか取れません。
POJOのAPI(メソッド)レベルの情報も、JDBCの情報も、SQLの情報も、全く採取されていません。
肝心のアスペクトが、まったくweaveされてないっぽいのです。

フォーラムにも似たような質問がいくつかあったので、結構、ひっかかるポイントなのかも。
何とかきちんと使える状態にできたら、そこら当たりのTipsを記録しておきたいと思いますが、今現在、途方に暮れていたりします。AspectWerkzのモジュールを指定したJVMオプションパラメータ-javaagentが効いてなかったり、アスペクトを定義したaop.xmlが間違っていたり、あるいは読み込めてなかったり、という辺りが怪しい気配なんですが、よくわかっていません。
明日の朝までに小人たちがせっせと編んでくれてたりしないかな。

またまた、事件です。
今度は、JMeterでStress Testを行うべく、まずは小手調べとしてサンプル的にWebアプリケーションの簡単な更新処理を実行しようとしていました。ところが、更新処理前までの画面遷移を行うためのGETメソッドは上手く実行できているのに、肝心の更新処理でPOSTしたリクエストを受けたアプリケーションの処理結果がエラーとなっています。

そのテスト計画(JMeterの動作を規定するシナリオのようなものです)は、以下の手順で作成したので、HTTPリクエストサンプラー(HTTPリクエスト処理を自動的に実行してくれるものです)の中のリクエストパラメータの定義に誤りがある訳もないし、と首をひねっていました。
(1) JMeterのProxy機能を利用して画面操作のリクエスト内容を採取
(2) 採取されて記録されたHTTPリクエストサンプラーの中のダイナミック変数などを適宜、編集
うん、ここのところで間違いはないはず。

で、問題の更新処理用のHTML中でJavaScriptが使用されていて、JMeterはレスポンスの中のJavaScriptを実行する訳ではないので、それが犯人かと追求したのですが、冤罪であることが判明しました。
そもそも、(1)の手順の最中でも、作成したHTTPリクエストサンプラーの実行の際でも、サーバー側に渡ったリクエストのパラメータが空っぽであることが、ベテラン刑事の厳しい取調べによって明らかとなったからです。ところが、JMeterに記録された送信リクエストの内容には、パラメータがびっしりと記載されているから、さあ、いよいよ謎は深まるのでした。

なんと真犯人は、multipart/form-dataの扱いに潜んでいたのでした(多分。状況証拠のみ)。
JMeterのHTTPリクエストサンプラーでは、ファイル添付のためのオプション項目が用意されているのですが、そこのパラメータ名とMIMEタイプを指定しておきながら、ファイルそのものの指定はしないと、ヘッダはmutipartでボディにはmultipartの区切りのないリクエストを送るみたいなことが、Bugzilla Bug 27780 に書かれているようです。
問題の更新処理用のHTMLには、ファイル添付の項目(input type="file")が用意されていて、formにもenctype="multipart/form-data"が指定されていたのです。そのせいで、(1)の手順の中で特にファイル指定はしていないにもかからわず、意識しないうちに、HTTPリクエストサンプラーのファイル添付のためのオプション項目のパラメータ名とMIMEタイプに、そのinput項目から引用された内容が記録されていたのでした。
そのオプション項目の指定を消すと、それまでの苦しみが嘘のように、更新処理は問題なく実行できたのでした。

めでたしめでたし。
いえ、喜んでばかりはいられません。今回も解決までに時間を要し過ぎ、あやうく迷宮入りさせてしまいそうでした...
初期の思い込みで捜査方針をミスリーディングしてしまったことを反省すると同時に、初動捜査の重要性を改めて思い知らされました。

Google で調べても日本語のページでは引っかからなかったので、自らの恥を晒します。

JMeter でリモート実行を試したら、Bad Call to Remote というメッセージが返されて、ちっともリモート実行されませんでした。 
どうも、リモート実行の要求を受ける側の PC で jmeter-server.bat を実行しても、エラーとなっているようです。
jmeter.log には、
java.net.MalformedURLException が発生して、
java.rmi.UnmarshalException が発生して、
java.rmi.ServerException が発生して、
で、ERROR - jmeter.engine.RemoteJMeterEngineImpl: rmiregistry needs to be running to start JMeter in server mode というエラーメッセージが記録されていました。

調べてみると、JMeter をインストールしたパスにスペースが含まれていると、この現象が発生するようで、実際、今回は"Program Files"の下に置いていたものを、スペースを含まないフォルダに移動したら解決しました。

これは、JMeter に原因があるのか、それとも Java RMI なのか、あるいは Java なのか ?
そこは目をつぶってます。きちんと問題発生の真の原因を理解することもなく、動いたから嬉しい、で私の中では一件落着しちゃっているからです。
そういう私の姿勢こそ、「お馬鹿」なんだよなあ、とわかってはいるのですが......これこそが最大の恥 ?