14

カスタム ソリューションを開発する前に、以下を提供するライブラリを探しています。

HTTP リクエストのノンブロッキング キュー

これらの属性:

  • 次の場合に失われないようにリクエストを永続化します。
    • ネットワーク接続の中断
    • アプリケーションが終了し、バックグラウンド アプリで GC が強制されました
    • 等..
  • これらすべてのフィールドを出力する可能性:
    • 住所
    • ヘッダー
    • 投稿データ

ですから、これを開発するのに丸一日節約できるものはありますか?

現時点では、要求が完了したときにコールバックを行う必要はなく、結果データを保存する必要もありません。

4

4 に答える 4

6

私の謙虚な意見では、Netty https://netty.io/などの洗練された接続処理フレームワークと洗練されたAkka http://akka.io/などの非同期処理のフレームワーク

最初にhttp://static.netty.io/3.5/guide/#architecture.8で http のNettyサポートの内部を見てみましょう。

4.3. HTTP 実装

HTTP は間違いなくインターネットで最も普及しているプロトコルです。サーブレット コンテナなどの HTTP 実装はすでに多数あります。では、なぜ Netty はそのコアの上に HTTP を持っているのでしょうか?

Netty の HTTP サポートは、既存の HTTP ライブラリとは大きく異なります。低レベルでの HTTP メッセージの交換方法を完全に制御できます。基本的には HTTP コーデックと HTTP メッセージ クラスの組み合わせであるため、スレッド モデルの強制などの制限はありません。つまり、思いどおりに動作する独自の HTTP クライアントまたはサーバーを作成できます。スレッド モデル、接続ライフ サイクル、チャンク エンコーディングなど、HTTP 仕様のすべてを完全に制御できます。

それでは、 Akkaの内部を掘り下げてみましょう。Akka は、Java 並行 API の上に優れた抽象化を提供するフレームワークであり、Java または Scala の API が付属しています。

  • アプリケーションをアクターの階層として構造化する明確な方法を提供します。
    • アクターは、不変メッセージを使用してメッセージ パッシングを介して通信するため、スレッド セーフを気にする必要はありません。
    • アクター メッセージはメッセージ ボックスに保存され、耐久性があります。
    • 俳優は子供たちを監督する責任があります
    • アクターは 1 つ以上の JVM で実行でき、多数のプロトコルを使用して通信できます。
  • Java Futures よりも使いやすい非同期処理Futureの軽量な抽象化を提供します。
  • Event Bus、ZeroMQ アダプター、Remoting のサポート、Dataflow の同時実行、Scheduler などのその他の優れた機能を提供します。

2 つのフレームワークに慣れると、それらを使用して必要なものを簡単にコーディングできることがわかります。

実際、必要なのは Netty でコーディングされた http プロキシであり、リクエストを受信するとすぐにFSMタイプのAkka アクター(http://doc.akka.io/docs/akka/2.0.2/java ) にメッセージを送信します。 /fsm.html)耐久性のあるメールボックス(http://doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html )を使用する

于 2012-08-08T11:15:49.177 に答える
2

これは、プラハのチェコ工科大学の学生の修士論文であったオープンソース ライブラリへのリンクです。これは非常に大規模で強力なライブラリであり、主に場所に焦点を当てています。ただし、良い点は、REST にあるヘッダーやその他の要素が省略されていることです。

これは最新のフォークであり、少なくとも「独自の」ソリューションのインスピレーションを与えてくれることを願っています。

于 2012-08-06T20:12:30.370 に答える
1

これらの同時コレクションはどうですか:

http://mcg.cs.tau.ac.il/projects/concurrent-data-structures

ライセンスが大丈夫であることを願っています。

于 2012-08-05T23:08:39.117 に答える
1

これらの投稿をご覧ください。（文書の最後に追加）

非常に基本的に、私にとって上手に機能するアプローチは、リクエストをキューとエグゼキュータから分離することです。リクエストは Runnable または Callable として実行されます。それらを継承して、API またはサービスへのさまざまな種類のリクエストを作成します。それらを実行する前に、ヘッダーや本文を追加してそこに設定します。

これらのリクエストをキューに入れます (どちらが適しているかを選択してください - LinkedBlockingQueueがジョブを作成すると思います) バインドされたサービス内からエグゼキューターにリンクされ、アクティビティまたはその他のスコープからそれらを呼び出します。応答とコールバックを取得する必要がない場合は、先物をリッスンするために Guava を使用しないようにするか、独自のコールバックを作成できます。

お楽しみに。さらに詳細が必要な場合は、特定のコードを投稿できます。ただし、最初のリンクに基本的な例のソースがあります。

http://ugiagonzalez.com/2012/08/03/using-runnables-queues-and-executors-to-perform-tasks-in-background-threads-in-android/

http://ugiagonzalez.com/2012/07/02/theres-life-after-asynctasks-in-android/

アップデート：

実行できなかったリクエスト用に別のキューを作成できます。私の頭に浮かぶ 1 つのアプローチは、失敗したすべての要求を再試行キューに追加することです。再試行キューはこれらのタスクを再実行しようとしますが、電話機はまだ何らかの種類のインターネット接続が利用可能であると認識しています。request オブジェクトでは、再試行の最大数を設定し、それを currentRetry 数と比較して、再試行ごとに増加させることができます。うーん、これは面白いかもしれません。私は間違いなくそれを私のライブラリに含めることを考えます.

于 2012-08-06T20:43:08.940 に答える