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.
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.
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.
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.
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
using Netty’s JNI edge-triggered transport, instead of using the JDK’s NIO.
Users can toggle on this feature by using the
Secure Mux (smux). We’ve added a STARTTLS command into the Mux protocol in order to support opportunistic TLS for ThriftMux.
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.
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.
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.
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 . 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.
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.
Christopher Coco and the Core Systems Libraries team