問題タブ [redisson]

Redission、redis Java クライアントをサンプル Java アプリに統合し始めました。を拡張するとすぐRedissonに、定義に近いエラーが発生しpackageます。

タイプ io.netty.util.concurrent.Future を解決できません。必要な .class ファイルから間接的に参照されている

これは何を意味するのでしょうか ？

redisson、またはベストプラクティスに関する適切なドキュメントはありますか?

と.getBlockingQueue()を許可する を使用していますが、キューの容量がわかりません。必要に応じて展開するように設定したいのですが、それがなければ、アイテムを試してみてキューがいっぱいになった場合、おそらくある程度の永続性が必要になると思います.offer()put()offer()

ドキュメントがまばらに見えるので、何を期待するかについて自信を持って使用するのは難しいと思います.

私は Jetty/CometD を介して長時間実行される Web サービスを実行しており、redis への接続に Redisson ライブラリを使用しています。RedissonClient/接続を取得するためにシングルトン パターンを使用していますが、それが最善の方法であるかどうかはわかりません。

クラスは次のようになります。

時間の経過とともにバージョンとブランチを進化させることができるエンティティ (ファイルまたはライブラリ/パッケージなど) が与えられ、バージョンを介してエンティティの特定のインスタンスに移動できるようにする最適化されたデータ構造を探します。

たとえば（少し不自然な例）、次のようなエントリが与えられます。

私は、そのようなものが既に存在しているのではないかと考えています (パッケージ管理またはソース コード管理は、上記のアクセス セマンティクスと同様のものを利用しているため)。

上記のメモリ内データ構造を探していましたが、最新/最古のアクセス時間は良好ですが、挿入/削除速度も下降しています。

残忍な力のアプローチでは、バージョンを持つことができるすべてのブランチに対してMin Max ヒープを使用して上記を実装できると思います。

とはいえ、もっと良いものがすでにあるかもしれません。これらのタイプのものの通常のソースであるRedissonもチェックしましたが、上記のデータ構造の明示的な実装があるかどうかはわかりませんでした

上記の DSL は私が独自に作成したものであり、おそらく穴もいくつかあるため、この種のデータ アクセスに適した DSL/API があれば、それも学びたいと考えています。

さまざまなマシンが Redisson を介して共有ロックを取得するインフラストラクチャを作成しようとしています。ロックが取得されると、いくつかの非同期タスクが完了し、最後に、ジョブを終了すると、現在実行中のスレッドを介して Redisson ロックを解放していますが、次のエラーが表示されます

ということで、その意味はわかりますが、非同期作業をしたいので、取得スレッドを使って解放することができません。

Redisson ロックを使用しない方がよいですか? そのような非同期作業に最適なものは何ですか?

タイトルが示すように、Redisson フレームワーク ( http://redisson.org )へのスプリング データ redis マッピングはありましたか?