🍂 Fall-ing for Finagle

As we move headlong into Autumn we thought this might be a good time to take a quick look back at some of the work from the previous quarter in Finagle, Finatra, Scrooge, TwitterServer, and Util and preview what we’re working on this quarter and beyond.

This covers the August and September releases as well as the upcoming release planned for this month. As mentioned before, we plan to continue this review regularly on a quarterly basis. You can start with a recap of what we were talking about last time.

News & Notes

Finagle’s 7th “birthday” (7th anniversary of the first public commit) is approaching. Stay tuned for a celebratory blog post! 🎉
We’re retiring the Finatra-specific blog, formerly available here. This will happen with our release this month. Unfortunately, we won’t be keeping any of the old posts but any new information will be shared on the Finagle blog here.

📣 New Features: HTTP/2 All The Things

Transparently replacing HTTP/1.1 usage with HTTP/2 continues internally. We’re really excited about this change and the improvements it brings. HTTP/2 gives you the resource reductions (a single multiplexed connection, request cancellations no longer require tearing down the connection) and resiliency features (fast rolling restarts without a success rate drop) that services are already accustomed to with Mux.

We encourage you to try it out by enabling the com.twitter.finagle.http.UseHttp2v2 toggle [1].

Efficiency

Metrics ‘verbosity’ level. Similar to logging levels in a logging API, we’ve introduced the concept of a verbosity level for metrics exported by Finagle [1, 2, 3, 4] with the ability for users to configure their service’s verbosity and to define a verbosity when creating a new metric.

For more information see the Util User’s Guide section on Leveraging Verbosity Levels.

Our internal roll-out of our new load balancer, Deterministic Aperture, continues and we’re excited about bringing this to the wider community soon!

We’ve completed the internal rollout of edge-triggered native transport using Netty’s JNI edge-triggered transport, instead of using the JDK’s NIO. Users can toggle on this feature by using the com.twitter.finagle.netty4.UseNativeEpollV2 toggle [1].

Operability

We’ll soon be open-sourcing the work done by our summer intern @McKardah to wire Twitter Futures into IDEA’s async stacktraces.

Security

Secure Mux (smux). We’ve added a STARTTLS command into the Mux protocol in order to support opportunistic TLS for ThriftMux.

Logging Improvements

We’ve been working hard to move TwitterServer to the SLF4J API and this should be merging in the near future. Stay tuned for updates and documentation on the changes.

Scrooge Updates

We’ve been making lots of changes to improve the usability and performance of Scrooge and Scrooge-generated code. This includes a set of refactorings to modernize the generated code so that it’s written in terms of Filters and Services!

This will allow us to address some long standing issues like server-side response classification and correctly stating on serialization/deserialization failures.

Additionally, we’re going to try to update libthrift from 0.5.0 to 0.10.0. This is still exploratory and we’re working to understand the ramifications.

Bringing Backup Requests Back

Finagle has had a BackupRequestFilter since late 2012 and it evolved into its current form in early 2013. The filter has a variety of what we would consider flaws (too many configuration knobs, less than ideal memory characteristics in many cases, lack of integration into the Stack-APIs and ClientBuilder to name a few) which has relegated it to Finagle’s experimental module.

We’re investigating what it would take to give users a single configuration variable – ideally the percentage of additional requests to send – to configure sending a backup request to another server.

‘Push’ based API for Protocols

Modern multiplexing protocols are characteristically very stateful and event driven which makes them challenging to implement with the current ‘pull’ based abstractions available in Finagle.

We are currently working towards the introduction of a Finagle ‘push’ based model which when coupled with a single threaded concurrency model will provide a more efficient and natural foundation for implementing multiplexing protocols.

Application-Level Streaming Research

Related to the above, Finagle has historically been dependent on request-response style protocols: a single request would be sent by the client and the server would reply with a single response. Then later multiplexing protocols to alleviate head-of-line blocking. However, all the protocols in Finagle are expressed as request-response APIs with some limited support for streaming through the use of Reader and AsyncStream [1]. These are somewhat low-level constructs and can be hard to use properly.

We are investigating the design of an API for bidirectional streaming of objects not just bytes. Stay tuned.

Blocking Code Detection

Our newest intern @andrewmccree14 is working on a project to help detect blocking code in Finagle. This should not only help users of Finagle but also allow for instrumentation and reporting (linting) of the blocking code. We’re really excited about this work and can’t wait to share it with the community.

Thanks for following along. As always, please feel free to ask questions on either the Finagle or Finatra mailing lists about anything that is unclear or if you would just like to know more.

Christopher Coco and the Core Systems Libraries team