Apache CXFがプリミティブをオブジェクト型に変換するのを防ぐには？

Question

私はプロジェクトのためにApache CXFを評価していますので、いくつか試してみるために小さなデモアプリケーションを作成しました。 CXFのユーザーズガイドに続いて、私は自分のアプリケーションを起動し、かなり速く動かすことができました。

私がテストしたかったのは、CXFが大量のプリミティブを返すメソッドをどれくらいうまく処理できるかということでした。だから私はメソッド 'float[] getRandFloats(int count)'を定義し、乱数で満たされた指定された長さの配列を返します。 java2wsdlによって生成されたWSDLを見ると、メソッドは戻り値の型が正しくfloat[]であることを示しています。クライアント側を調べると、私も（最終的に）float[]を受け取っていることがわかります。

配列の要素数を増やすと、クライアントのパフォーマンスが低下することがわかりました。私はクライアント側でプロファイラを実行し、返された配列のすべての要素に対してオブジェクトが作成されていることを確認しました。これは、CXFが応答の解析中にJAXBを呼び出すときに起きているようです。

私は、このオブジェクトの作成が非常に望ましくないように、何百万もの浮動小数点数を返す可能性のあるアプリケーションで使用するためにCXFを評価しています。 CXFを使用するには、このオブジェクトの作成を防ぐ方法を見つける必要があります。ドキュメントとメーリングリストをスキャンしましたが、これを回避する方法はありませんでした。

誰もCXFを使用して同様の問題が発生しましたか？もしそうなら、どうやってこれを回避できましたか？

Answer 1

これは間違いなくCXFが何でもできることです。これはJAXBの問題です。私は内部的に、JAXBはすべての "maxOccurs！= 1"のケースを配列ではなくJavaコレクションとして扱うと信じています。必要に応じて、プロセスの最後のステップとして配列に変換するだけです。 Javaコレクションはプリミティブを保持できないため、格納されているFloatオブジェクトになります。

いずれの場合でも、これはJAXBの人々に引き継がれる必要があります。 :-(

Answer 2

あなたはclierntパフォーマンスは、アレイ増加の要素のアンバーとして苦しんでいると言います。これは私にとっては妥当だと思います。データが増え、パフォーマンスが低下します。何を期待していたのですか？それが線形の劣化である限り、それは正常に動作しています。

数百万のオブジェクトを作成する場合、現代のJVMは汗をかくことなくこれを行います。私はCXFのデザイナーがこれをよく知っていると思う。古いJVMはGCアルゴリズムが貧弱で、何百万ものオブジェクトが蹴られていましたが、これはもはや問題ではありません。

一方で、多くのデータと、何百万ものオブジェクトが作成されているため、パフォーマンスが低下しています。しかし、2つの観察結果が関連しているという証拠はない。