Summer Update ☀️
Hello Finaglers,
Summer ⛱️ is now in full-effect around the world 🌍 but we interrupt your travel 🚙and ice cream 🍦 to quickly highlight the 🆒 things released over the spring and early summer 🐚 months of April, May, and June. Just a note, if you’d like to keep up-to-date on all that is happening in a more real-time ⏰ fashion please feel free to watch ⌚ our project changelogs [1, 2, 3, 4, 5].
TwitterServer
Users of TwitterServer can now see client connections to the server via the “/admin/servers/connections.json” admin page.
Streaming
We’ve continued rolling out Finagle streaming HTTP updates and improvements including adding more metrics for visibility including request/response streaming durations and a new StreamingStatsFilter which tracks various request/response metrics.
Netty Upgrade
We also upgraded our Finagle Netty4 dependency to Netty 4.1.35.Final.
Finagle
Have you wanted a way to easily shift your application work off of the I/O threads? Good news — now you can. By default, Finagle executes all Futures in the I/O threads minimizing context switches. Since there is typically a fixed number of I/O threads shared across a JVM process, it is very important to ensure they’re not blocked by application code and thus affecting a system’s responsiveness. Shifting application-level work onto a dedicated FuturePool or ExecutorService which offloads work from the I/O threads can improve throughput in CPU-bound systems. Note, you can also do this globally for your process by setting the com.twitter.finagle.offload.numWorkers flag.
Stats and retry modules use a ResponseClassifier to give hints for how to handle failure (e.g., Is this a success or is it a failure? If it’s a failure, may I retry the request?). The StatsFilter increments a success counter for successes, or increments a failure counter for failures. There isn’t a way to tell the stats module to just do nothing. But this is exactly what the StatsFilter should do (nothing) in the case of ignorable failures (e.g. backup request cancellations). To represent these cases, we introduce a new ResponseClass: Ignorable.
Finagle-MySQL SSL/TLS
The MySQL protocol contains support for SSL/TLS via messages sent when establishing a connection. However, finagle-mysql did not support the sending of the messages in the correct sequence in order to properly negotiate SSL/TLS with a MySQL server. We’ve updated finagle-mysql to now support using SSL/TLS with MySQL which can be enabled by calling withTransport.tls(sslClientConfiguration) on MySQL client and specifying a c.t.f.ssl.client.SslClientConfiguration.
Jackson Upgrade
We updated several of our libraries to Jackson 2.9.8 [1, 2, 3, 4].
Finatra
Finatra’s HTTP integration uses code from the javax.activation library which was deprecated in JDK 9 and fully removed in JDK 11. We’ve updated to specify an explicit dependency on the 3rd party com.sun.activation library as a temporary measure until we can evolve the library away from using the javax.activation library. This allows for using Finatra HTTP services with JDK 11 without having to specify any additional dependencies.
Additionally, we’ve made several changes to make testing more flexible. You can now specify values for global flags when creating an EmbeddedTwitterServer. This allows users to write tests which will not trample over each other since global flags are typically only read once on JVM startup.
We’ve also updated the Finatra EmbeddedTwitterServer to allow users to bring their own StatsReceiver implementation. In testing with the EmbeddedTwitterServer, Finatra bound an InMemoryStatsReceiver instance to the object graph for any injectable TwitterServer. However this prevented users from being able to use and test against their own StatsReceiver implementation.
Thanks for following along. If you’d like to know more about any one of these updates, or if you have a question about them, join us on the Finagle or Finatra mailing lists or hop on Gitter.
Enjoy! 🕶️
Christopher and the Core Systems Libraries team