2017-07-10 4 views
0

私はexampleを見つけました。ここでakka-httpはSource.singleでリクエストを行うために使用されています。今、私はこのようなX秒ごとに実行されているポーリング要求を実装するためにSource.tickを使用したい:しかしAkka-Httpストリームによるポーリング

import scala.concurrent.duration._ 
    val request: _root_.akka.http.scaladsl.model.HttpRequest = RequestBuilding.Get(Uri("http://api.someSite.com")) 
    val source: Source[HttpRequest, Cancellable] = Source.tick(1.seconds, 1.seconds, request) 
    val sourceWithDest = source.via(Http().superPool()) 

を、私は私が解決カント最後の行(型の不一致)でコンパイルエラーが発生します。私が間違ってやっていることや代替案の提案に関するアイデアはありますか? docs 1として

答えて

2

:。

フローは、HTTP(によって返された)superPool(...)は、ホストレベルクライアント側APIから1 と非常によく似ているので、使用しますホスト接続 プールセクションもここで適用されます。 。

Flow[(HttpRequest, T), (Try[HttpResponse], T), HostConnectionPool]

この: HTTP()cachedHostConnectionPool(...)によって返さ

そしてthen

「プールクライアントの流れは、」次の型を持っていますクライアント側のコードに、元の要求と対応する応答を一致させるロジックを実装する可能性を与えることです。このような振る舞いが必要でないと仮定すると、プールフローに供給する前に、いつでもNotUsedを要求に追加して処理を進めることができます。例えば。

val sourceWithDest: Source[Try[HttpResponse], Cancellable] = 
    source.map(req ⇒ (req, NotUsed)).via(Http().superPool[NotUsed]()).map(_._1) 
+0

ランダムなものではなく、プレースホルダの値として「Unit」や「NotUsed」のようなものを使用するのはもっと慣れていると思います。 –

+0

非常に正しいです、NotUsedが最良の方法でしょう –

+0

答えをありがとう。おそらく、マッチングが使用されている例や、もう少し説明されている例を見てみましょう。私はちょっとあなたが話していることを理解しているが、私はもう少し読書が必要だと思う。 – PhilBa

関連する問題