Scala调度重启超时答案

【问题标题】：Scala dispatch reboot timeoutScala调度重启超时
【发布时间】：2013-02-08 17:40:24
【问题描述】：

我在我的项目中使用调度重启库版本 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 ) )

（我相信第三行设置了我自己的线程池，一个线程，超时10秒）。

然后我重复运行此代码（在粘贴模式下），提交未来以获取特定 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 个调用，它按预期工作。然后它可靠地无法报告成功的页面回复或异常。我的假设是，如果这是由超时引起的，我应该期望回调在 10 秒后触发，Either 的 Left 子句包含某种形式的超时异常。但我的经验是，这永远不会发生。

谁能帮忙告诉我我做错了什么？

更新

顺便说一句，我知道有一个类似的问题（有答案）here，但我正在寻找官方（即图书馆作者打算）处理超时的方式 - 在我看来，这是 waiting 方法的用途

【问题讨论】：

“重启”部分是关于什么的？
@RandallSchulz 我相信重新启动是使用 async-http-client 作为传输的重写，并且还为那些有些过敏的人公开了更多可选的 java-y api到原始符号方法的数量。

标签： scala asynchronous future scala-dispatch

【解决方案1】：

所以一个答案，虽然我不太满意 - 因为它涉及忽略 Http 上相当漂亮的 waiting 方法并直接使用 async-http-client apis 是这个（灵感来自问题更新中链接的SO帖子）：

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

        builder
    }

我的代码现在按预期运行。哼哼……

【讨论】：