This release is intended to accommodate Finagle 6.42 with its brand-new Netty 4 support. As of Finch 0.13, you may now (and should!) switch the underlying transport implementation over to Netty 4.
Netty 4 support
Historically, Finch was using some Netty 3-specific optimizations (i.e., hacks) to perform zero-copy retrieving of the HTTP payloads. In this release, we made everything Netty-agnostic and made sure it's still as efficient as it was before. This means you may now consider switching the underlying transport over to Netty 4 not worrying about potential performance penalties.
Switching to Netty 4 right now means staying aligned with future resiliency and performance improvements in finagle-http. At this point, there is no known difference in the throughput between finagle-http servers running Netty 3 and Netty 4. However, several major improvements for Netty 4 HTTP transport are planned to be shipped in the future Finagle releases. To mention a few: memory pooling (fewer allocations) and HTTP/2 support.
To jump into the Netty 4 land, supply the following CLI flag to your Finch application:
-Dcom.twitter.finagle.toggle.flag.overrides=com.twitter.http.UseNetty4=1.0
Or specify Netty 4 implementation programmatically on your Http.Server instance:
import io.finch._
import com.twitter.finagle.Http
import com.twitter.util.Await
Await.ready(
Http.server
.configured(Http.Netty4Impl)
.serve(":8081", Endpoint.lift("foo").toServiceAs[Text.Plain])
)Other changes
- There is now a
Dateheader severed along with any Finch response (as it's required by spec). See #730 (thanks @n4to4) - 10 seconds startup delay and Netty warning on Scala 2.12 are now fixed in Finagle 6.42