問題タブ [chronicle]

待ち時間の影響を受けやすいアプリケーションで Indexed Chronicle キュー (バージョン 3.4.3) を使用しています。遅延の急増を緩和するために、プロデューサーがメッセージをドロップするクロニクルの前にブロッキング キューを用意しました。次に、バックグラウンド スレッドがキューをポーリングし、データを Chronicle に書き込みます。

クロニクルをウォームアップするテクニックがあるかどうか知りたいですか? 一定数のメッセージをエンキュー/デキューすることで、ブロッキング キューをウォームアップします。それらのメッセージをクロニクルに書き、それをきれいにしてウォームアップする必要がありますか?

ありがとうございました

VanillaChroncile を使用してエントリを一時的に保存および取得していますが、負荷が大きい場合を除いて、すべて正常に動作します。マップ失敗例外が発生します。この例外を処理する回復ロジックはありますが、そもそもなぜ例外が発生するのか知りたいです。どんな助けでも大歓迎です。

}

全て、

クロニクル マップに時系列を保存しようとしています。シリーズはチャンクに分割され、各チャンクは個別のマップ エントリです。エントリが Chronicle Map に現在書き込まれている間 (BytesMarshaller がシリアル化されている間)、JVM が終了するとどうなるか誰かが知っているかどうか疑問に思っています。

メモリ マップされたファイルは破損したデータになってしまいますか?? 回避策はありますか??

クロニクル マップがどのように機能するかについての情報が必要です。いくつかのキーと値のペアをメモリに保持し、格納する値の特定のしきい値をオーバーフローすると、データがディスクにオーバーフローするか、メモリ サイズに依存するかのようなものですか?マップのサイズがしきい値を超えて大きくなり、データがディスクにオーバーフローします。その場合、どのように構成できますか、または他の戦略はありますか?

同じマシンで 2 つの Java アプリケーションを実行しています。リモート接続の要件があったため、http を介した jvm 間通信を実装しました。ある仮想マシンから別の仮想マシンに、約 10MByte の画像データを 1 秒間に 100 回渡しています。http では、書き込み機能に時間がかかりすぎたため、大幅な遅延が発生しました。速度が最も重要な基準であるため、要件として http をスキップできます。次に、ソケットを試しましたが、それでも遅すぎます。高速な jvm 間のメッセージングについて、RMI と Chronicle (openhft) について読みました。クロニクルは、メッセージの受け渡しにクロニクル キューを使用し、画像データの共有にクロニクル マップを使用できるので、興味深いと思います。

しかし、正直なところ、何が最善かを見積もることはできません。使用例は次のとおりです。 サーバーは画像を収集します。クライアントは、利用可能なイメージのリストを要求します。クライアントがメッセージを受け取るとすぐに、クライアントは 1 つの特定のイメージを要求します。サーバーには既にイメージがロードされており、イメージをクライアントに送信する必要があります。使用する戦略について何か提案はありますか? すべての画像をクライアントに送信することもできますが、これにより、サーバーが不要なデータ送信に多くの時間を費やすことになります。

ヒントをありがとう。

Java インメモリでは、byte と int の間に違いはありません。どちらも 4 バイトとして表されます。

クロニクル マップには違いがありますか。つまり、クロニクル マップはバイト値を 8 ビットとして保存するのですか、それとも 32 を使用しますか?

byte がオブジェクトプロパティである場合も同じ質問です。

net.openhft:chronicle:3.5.3 を使用するこのプログラムは、私が Chronicle で抱えている次の問題を示しています。

1 Vanilla Chronicle.size() がクレイジーな値を返す

2 ExcerptTailer.toStart がインデックス付きクロニクルで機能しない

3 ExcerptTailer.index(-1) が Vanilla Chronicle で機能しない