and servers • Need for predictable performance • Communication between different languages • Isolated computations • Fan out, Fan In distributed systems • ...
• Different from scala.concurrent.Future and java.util.concurrent. Future • Less context-switching, easier cancelability • From com.twitter.util.Future • Composables • Error and Exception Handling
1.second, DefaultTimer.twitter) val myService = new DummyService val service = myService andThen myTimeOutFilter val server = Httpx.serve( “:8080”, service) Await.ready(server)
• One network connection per client-server session • Maximization of available bandwidth without incurring the cost of opening additional sockets • Elimination of head-of-line blocking • Explicit queue management • Pure session layer (OSI )
Twitter built on top of Finagle • Flags for configuration • Logging and Metrics • Admin HTTP UI • Lifecycle management endpoints, handy for Docker and/or Mesos • Tracing via ZipKin
API Services on top of the Twitter Stack (Finagle, Twitter-Server, Twitter-util, etc.) • Supports Http and Thrift services • Brings Sinatra like Style to Finagle for Rest Services
basic blocks, to build composable REST APIs. • Built on top of Finagle • Functional wrapper of Finagle-http • Performance close to Bare Metal Finagle http://github.com/finagle/finch
tracing system that helps us gather timing data for all the disparate services at Twitter. It manages both the collection and lookup of this data through a Collector and a Query service. • Implementation of Google’s Dapper paper • Moved to OpenZipkin
old versions of Netty. Currently Netty 3 and now moving to 4 • API Changes since 6.x. No more Netty API Leaking through Finagle’s • Mismatch between scala.concurrent.Future and com.twitter.util.Future • Slow to update • Documentation not exhaustive. Thanks for gitter.im and the Mailing List • Can be painful to plug to other Metrics and Monitoring systems. Hopefully it’s changing