1

プロジェクトでディスパッチ リブート ライブラリ バージョン 0.9.5 ( http://dispatch.databinder.net/Dispatch.html ) を使用しています。sbt経由で次の行があります：

libraryDependencies += "net.databinder.dispatch" %% "dispatch-core" % "0.9.5"

scala (2.9.2) repl (sbt console適切な依存関係を取得するために使用を開始) で、私のコードとは無関係に、次のセッションを実行します。

import dispatch._
import java.util.concurrent.TimeUnit._
val spoo = Http.threads(1).waiting( Duration(10, SECONDS ) )

(3 行目は、1 つのスレッドと 10 秒のタイムアウトで独自のスレッドプールを設定していると思います)。

次に、このコードを (貼り付けモードで) 繰り返し実行し、future を送信して特定の URL をフェッチし、ステータス コードを (非同期で) 出力します。

spoo(url("http://www.evapcool.com/products/commercial/")).either
    .map {
        case Right(r) => println( "S: " + r.getStatusCode())
        case Left(e)  => println( "E: " + e.toString ) }

この行を実行するたびに、ステータスコードが出力されるのを待ってから、行を再度実行します。最初の 20 ～ 40 回の呼び出しでは、期待どおりに機能します。次に、成功したページ応答または例外のいずれかを確実に報告できません。これがタイムアウトによって引き起こされた場合、何らかの形式のタイムアウト例外を含むLeft句を使用して、10 秒後にコールバックが起動することを期待する必要があると想定しました。Eitherしかし、私の経験では、これは決して起こりません。

私が間違っていることを教えてくれる人はいますか？

アップデート

ちなみに、ここに同様の質問（回答付き）があることは承知していますが、タイムアウトを処理する公式の（つまり、ライブラリの作成者が意図した）方法を探しています-そして、これがそのwaiting方法であるように見えますのために設計された

4

1 に答える 1

2

だから答えは、私は非常に満足していませんが、かなり見栄えの良いwaitingメソッドを無視Httpし、async-http-client APIを直接操作する必要があるためです(質問の更新にリンクされているSO投稿に触発されました):

val spoo = Http.threads( 1 ).configure
    { builder =>
        builder.setRequestTimeoutInMs( 10000 )
        builder.setConnectionTimeoutInMs( 10000 )

        builder
    }

私のコードは期待どおりに実行されるようになりました。うーん...

于 2013-02-10T16:12:39.957 に答える