問題タブ [kryo]

私のScala NLP（自然言語処理）アプリで、比較的単純な構造であるが大きくて作成に時間がかかるいくつかのクラスをピクルしようとしています。大量のデータがあるため、ピクルと esp が必要です。膨張せずにすばやく解凍します。Java のシリアライゼーションは、この点で明らかに問題があります。Kryo については知っていますが、使用したことはありません。私は Apache Avro にも遭遇しましたが、これは似ているように見えますが、通常、適切なソリューションとして言及されていない理由はよくわかりません。どちらも Scala 固有ではなく、Scala Pickling と呼ばれる Scala 固有のパッケージがあるようです。残念ながら、ほとんどすべてのドキュメントが不足しており、カスタム ピッカーを作成する方法がわかりません。

ここに質問があります：

Scala Pickling: ネストされた構造のカスタム pickler / unpickler を書く

その質問にはまだいくつかのコンテキストが欠けています。また、Kryo や Avro の例と比較して、カスタム ピックラーを作成するには非常に多くのボイラープレートのように見えます。

シリアル化する必要があるクラスの一部を次に示します。

できるだけボイラープレートを使用しない方法でカスタムピッカー/アンピッカーを作成するにはどうすればよいですか (同様の処理が必要な他のクラスが多数あるため)。

ありがとう！

バックグラウンド

オブジェクトの配列に (コードの変更により) デシリアライズできないオブジェクトが含まれている場合、配列内のそれらの参照が例外をスローするのではなく null になるように、Kryo デシリアライゼーションを記述しようとしています。オブジェクトの残りを回収できるようにします。私は以前にJavaの組み込みのシリアライゼーションを使用していましたが、配列内の各アイテムの間に「既知の適切な」整数を書き込み、エラーが発生した場合はストリーム内でそれを探すことでこれを達成することができました次のオブジェクト。これは、いくつかの非直列化可能オブジェクトを含む配列を非直列化する (非直列化可能部分のサルベージ) という質問の詳細です。

効率の理由から Kryo のシリアル化に移行し、このアプローチを再作成しようとしましたが、Kryo 内ではこのエラー回復が一度は機能しているように見えますが、その後は正しく回復しません。

私が試したこと

シリアライゼーション中END_OF_APPLE_MAGICに s の配列内の各オブジェクト間に既知の適切な integer( ) を書き込もうとしました。逆シリアル化中に、逆シリアル化できないApplea が見つかった場合、それは an に置き換えられ(アナロジーが弱くなっています) 、次のリンゴを探す場所を見つけるために が検索されます。これは、配列内に 1 つがあり、それが最初のエントリでない場合に機能します。しかし、配列に複数の配列がある場合、または最初の配列がBadAppleErrorAppleEND_OF_APPLE_MAGICBadAppleBadAppleBadAppleAppleBadApple

質問

一部のオブジェクトのみがデシリアライズ可能である Kyro のシリアライズされた配列をどのように救済できますか? ErrorAppleこれにより、非シリアル化可能部分のエントリを含む配列を取得します。私の配列内には、単一の配列内の同じオブジェクトへの複数の参照があります。これが逆シリアル化プロセスで保持されることが不可欠です。

だから私が持っている連載に入る

そして、私が望む逆シリアル化から出てきます（badAppleが変更され、逆シリアル化できないため

これにより、下位互換性を達成できない場合、または以前にインストールされたプログラムに対するサードパーティの変更が削除された場合にフォールバックを提供したい

詳細な分析

このセクションでは、既存のプログラムが失敗する方法について概説します。

一般に

• BadApple配列の最初の位置以外の場所にあるシングルは正しく機能します
• 配列の最初の位置にあるAは、次の読み取りに正しくBadAppleつながり、それ以降は (良いs であっても)AppleErrorApplesApple
• 複数ある場合BadApple、最初の goodAppleは 2 番目の後にBadApple正しく読み取られますが、配列内で前方に移動され、それErrorApples以降 (goodAppleの場合でも) 移動される可能性があります。がありKryoException: Buffer underflow、配列の最後に null エントリがある場合があります。

私が使用した入力と出力を以下に示します。

Oracle Java を使用して、Ubuntu 12.04.3 x64 VPS で Java アプリを実行しています。数分後、OS によってプロセスが強制終了されます。コンソールに「killed」と表示されます。

クラッシュの前に、TOP (数ギガバイトの仮想メモリ) を使用して過度のメモリ使用量を確認できます。リークを調べるために、Java VisualVM をインストールし、jstatd を介してリモートで接続しました。漏れの兆候は見られません:

• ヒープサイズ: 10 MB
• PermGen スペース サイズ: 20 MB
• スレッド: 5
• 読み込まれたクラス: 815

数回試行した後、hs_err_pid7071.logとhs_err_pid7057.logがアプリ ディレクトリ (リンク) に表示されました。

アプリで使用されるネイティブ ライブラリがいくつかあります。

実行 して、この結果jcmd 8749 VM.native_memory detailを得ました。VM は、その時点で約 2 GB のメモリを使用していました。

この行を削除すると、リークが消えます。

このメソッドのドキュメント

Kryo 2.22 ライブラリを使用してオブジェクトをファイルにシリアル化しています (パフォーマンスのために UnsafeInput/Output を使用しています)。

私のオブジェクトには、1 つの文字列を含む多くのフィールドが含まれています。この文字列が 35 文字以内であれば問題ありません。これを 2 倍にして 70 文字までにすると、ファイルから逆シリアル化するときに次の例外が発生します。

文字列の長さを 2 倍にするときは、最初のコンテンツをコピーしただけです (つまり、追加の特殊文字は導入されていません)。

したがって、私の最初の推測では、オブジェクト サイズの増加に関連しているということでした。Kryo バッファー サイズを 2 倍にしましたが、それでも例外がスローされます。

私は今、問題を見つけるのに何時間も費やしており、絶望的になっています。ヒント/提案をいただければ幸いです。

どうもありがとう、トーマス

更新:ようやく問題が見つかりました: 子クラスをシリアル化し、親クラスを逆シリアル化していました。役に立たなかったのは、Kryo が矛盾して例外をスローすることです (この場合、文字列のサイズに依存していました)。

SimpleDirectedGraph をシリアライズしようとすると、次のエラーが発生します。

このタイプのエラーに関するインターネット検索では、ASM 4.0 ライブラリへのユーザー アップデートを推奨する多くの人が返されます。ASM 4.0 ライブラリを含む Kryo 2.2 All を使用しています。念のため、ASM 4 ライブラリを単独で含めてみましたが、うまくいきませんでした。

ArrayList などの単純なオブジェクトをシリアル化してみました。それらはうまくいきます。kryo がこのグラフ クラスのシリアル化に失敗する理由がよくわかりません。誰にもアイデアはありますか？

更新: 私はグラフを扱っているので、kryo の実験的な「継続」ブランチを実装してみましたhttps://github.com/EsotericSoftware/kryo/issues/103

残念ながら、私はまだ同じエラーを受け取ります。

更新:トリックは、別の種類のシリアライザーを使用している可能性があると思います。残念ながら、SimpleDirectedGraph で動作するものを見つけることができないようです。BeanSerializer は、最初のオブジェクト レイヤーのみをシリアル化します。ネストされたオブジェクトはシリアル化されないようです。他のシリアライザーは、FieldSerializer と同じエラーをスローします。人々が通常グラフで使用するシリアライザーはありますか?

これはよくある問題のようですが、トラブルシューティングに多くの時間を費やした後でも解決策を見つけるのに苦労しています. 更新されたソリューションがあることを願っています。

KryoNet Java ネットワーク ライブラリを使用して、単純なサーバーとクライアントをセットアップしています。私の問題は、サーバーに接続した直後にクライアントが切断されることです。

これが私のコードです：

サーバ

クライアント

を実行TheServerした後TheClient、コンソールに次のように表示されます。

接続と切断の間の時間はほぼ即時であり、設定した接続タイムアウト時間よりも確実に短いことに注意してください。setKeepAliveTCP()また、必要ではないと思いますが、機能するかどうかを確認するために挿入したため、メソッドをコメントアウトしたことにも注意してください。