Can I set a timeout and number of retries on a specific pipeline request?

4.2k views Asked by At

When using spray's pipelining to make an HTTP request like this:

val urlpipeline = sendReceive ~> unmarshal[String]
urlpipeline { Get(url) }

is there a way to specify a timeout for the request and the number of times it should retry for that specific request?

All the documentation I've found only references doing in a config (and even then I can't seem to get it to work).

thx

2

There are 2 answers

0
Tim Van Laer On BEST ANSWER

With the configuration file

I use Spray 1.2.0 in an Akka system. Inside my actor, I import the existing Akka system so I can use the default Akka configuration file.

implicit val system = context.system
import context.dispatcher
val pipeline: HttpRequest => Future[HttpResponse] = sendReceive

Now you can change the configuration in application.conf.

spray.can.host-connector {
    max-connections = 10
    max-retries = 3
    max-redirects = 0
    pipelining = off
    idle-timeout = 30 s
    client = ${spray.can.client}
}

In code

It is possible to change the settings in code using the HostConnectorSetup, but you have to define all parameters. (Based on the spray usage example.)

val pipeline: Future[SendReceive] =
for (
  Http.HostConnectorInfo(connector, _) <-
  IO(Http) ? Http.HostConnectorSetup("www.spray.io", port = 80, settings = Some(new HostConnectorSettings(maxConnections = 3, maxRetries = 3, maxRedirects = 0, pipelining = false, idleTimeout = 5 seconds, connectionSettings = ClientConnectionSettings(...))))
) yield sendReceive(connector)
2
Daryl Odnert On

I believe that the easiest way to override the default timeout in code is to use the implicit futureTimeout argument to the sendReceive method. The data type of that parameter is akka.util.Timeout. So, if you wanted a 120 second timeout instead of the default 60 seconds, you can do this...

implicit val timeout = Timeout(120 seconds)
val urlpipeline = sendReceive ~> unmarshal[String]
urlpipeline { Get(url) }

However, I don't see any parameter that would allow your client code to change the maximum number of retries in a similar fashion.