Dispatch v0.13.0-M2

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.13.0-M2. This release is a milestone pre-release for the v0.13.x series. The change log for this release can be viewed on GitHub.

This release will become the final v0.13.0 release on June 15th, 2017, unless any major bugs are reported and need to be fixed.

Below are some highlights from this release since v0.13.0-M1:

Http singleton is no longer an executor, using Http.apply is now deprecated

Since Dispatch started, you've been able to use the HTTP singleton to make requests to HTTP services directly. For example:

Http(myReq > as.String)

This usage is now deprecated. The long in short here is that treating the Http singleton created a good bit of awkwardness when it came to figuring out how to deal with cases where people needed a custom configuration for their HTTP executor. We got many, many bugs over the years where people would invoke configure on the Http singleton and end up with a resource leak. It also wasn't clear that even referencing the Http singleton somewhere would allocate resources.

Furthermore, it was easy for people to make the mistake of writing something to the effect of:

for (task <- myBatchTasks) {
  val exec = Http()
  exec(...)
}

and ending up with a huge resource leak in their application.

To combat this a few specific changes have been made:

• If you want to create a new instance of the Http case class directly, you'll have to manually provide a client builder instance. You can use Http.defaultClientBuilder directly or as a starting point, but this should hopefully make it harder to fat-finger a resource leak in your application.
• Http.default is the new way to use a default, globally available executor. It's a lazy val and won't allocate resources until it is accessed.
• The apply methods on the Http singleton still work to ease in migration, but will use Http.default under the hood and throw a deprecation warning on compile.
• The Http singleton is no longer an instance of an executor, so invoking things like Http.configure will no longer work. We instead provide Http.withConfiguration which will vend a new executor with your desired configuration without allocating resources on the default executor.

The configure method on executors is now deprecated

Part of the motivation for the Http singleton changes from above was the fact that in the old world you could invoke the .configure method on the Http singleton. There were a number of pull requests that suggested solutions for this and several of them were implemented. Including, in 0.13.x, having the Http case class take a ClientBuilder instead of a DefaultAsyncHttpClient.

However, we were still faced with needing to make a breaking API change.

The configure method in its old form could still create resource leaks that couldn't be resolved if used in its old form. To fix this problem a new method, closeAndConfigure has been added to the Http case class. This method will first close the underlying client in the executor, and then return a new instance of Http with the requested configuration.

In the future, if you need to create a new Http instance while leaving your old Http instance functional, we recommend manually invoking the copy behavior on the case class. Something like:

import org.asynchttpclient._

val myHttp1 = Http.default
val newBuilder = new Builder(myHttp1.clientBuilder.build)
val myHttp2 = Http(newBuilder)

In the example above, myHttp1 and myHttp2 are both still usable and it's explicit to the developer that they have allocated additional resources.

This method is consistent with the methods added in the 0.12.x series and allows you to continue using .configure if that's what you really want to do. My hope is that this will make migrating to the new, "correct"