2012-04-10 6 views
3

Clojureインタプリタを含む "lein uberjar"でビルドされたClojureのBaseX用プラグインを作成しています。ほとんどの場合、これはうまくいきます。JVMのスレッドローカル空間からClojure変数をアンロード

しかし、BaseX HTTPインスタンス経由で実行する場合、クライアントが切断された後にスレッドを破棄するのではなく、Jettyのスレッドプール内で評価が行われます。

プラグインをロードすると、Clojureのクラスがカスタムクラスローダーに読み込まれ、プラグインのエントリポイントとして機能する(AOTコンパイルされた)オブジェクトインスタンスがスローされても、Clojureによって配置された変数はスレッドローカル空間で破棄されません。 Clojureインタプリタの複数のインスタンスによって最終的にPermGenスペースが使い尽くされてリークします。

どうすれば解決できますか?必要に応じて、BaseXのモジュールロード/アンロード機構に対して、適切な非Clojure固有の変更を行うことができます。

答えて

1

このアイデアかもしれない(またはかもしれない)仕事:

  1. 、uberjarを行い、別のClojureのjarファイルを保管しないでください。

  2. push Clojureは、BaseXのメインクラスパスにクラスローダー階層を入れます(java -cp BaseX.jar;clojure.jar org.basex.BaseXServerなどのBasexXサーバーを起動するコマンドラインを編集します)。

  3. あなたのプラグインをあなたのコードだけでパッケージ化し、メインクラスパスに既に存在するClojureクラスに依存してください。

+0

これは実際に私が回避策として現在行っていることです。 ClojureをBaseXインストールの一部として含めれば、間違っていると思うからです。プラグインが依存関係を変更するたびにデータベースのインストールを変更する必要があります。単に清潔ではない。 –

+0

まあ、Clojureは結局のところ、古いjarの依存関係だけでなく、完全な言語実行環境です。私にとっては、このアプローチはBaseX Clojureを有効にするようなものです。他のすべての依存関係は、プラグインのローカルに保持することができます。使用しているClojureのバージョンを変更することはしばしばではなく、BaseX自体をアップグレードするよりも、それほど頻繁ではありません。 –

+0

私はそれが本当だったことを望みます - 私はClojure 1.3.0のバグを打ち、既に1.4ベータシリーズへの移行を余儀なくされました。 (2番目のプラグインがClojure 1.1のようにしか書かれていない場合、これは非常に不幸な状況になります)。より重要な点として、*「すべてのjar依存関係」は、操作上の観点から、「ちょうど古いjar依存」として動作できないようにすることは、少し残念です。そういうわけで、これを修正するべきものとして扱うことは合理的だと思います。 –

関連する問題