Async servers and clients in Rest.li

Editor's Notes

1. R2 – RESTful abstraction built on Netty and Jetty. D2 – Dynamic discovery and client side load balancing using ZooKeeper. Rest.li – Data layer + layer that exposes RESTful API that application can use to build RESTful services.
2. Async I/O basically means that we free up our thread of computation to do other things while we are waiting for the I/O to complete. In other words we make an I/O request and we don’t block waiting on the result of the I/O to appear. Let’s look at one thread on the server. Assume both request 1 and request 2 arrive at the same time. In each request the thread does some work, then makes an I/O request of some sort, and then uses the values from the I/O response to fulfill the request. In the synchronous model we can’t start processing request 2 until request 1 is done because the thread is blocked on I/O. In the gray portions our server is essentially idle. In the async model we can start processing request 2 instead of blocking on the I/O to complete.
3. For the rest of the talk we will assume we are running the R2 server in async mode.
4. Jetty configuration is needed to run Rest.li in async mode. If you are running Rest.li in a thread-per-request model async programming will not make much of a difference since the thread cannot be re-used to serve new requests.
5. ParSeq is a framework that makes it easier to write asynchronous code in Java. Created by LinkedIn and is an open source project.
6. In this example we are fetching data from ZooKeeper using the async ZooKeeper API and then converting that data into a Greeting object to return.
7. Need to explicitly specify the callback in the method signature. Notice the void return type. The next slide will explain how a response is sent back to the client.
8. The callback API exposes two methods – onSuccess and onError. In this example we invoke the onSuccess method if the data we get from ZooKeeper has a length > 0. We invoke the onError method otherwise. Once either onError or onSucess has been invoked the framework will return a response back to the client.
9. ParSeq is a library that makes it easy to write complex async task flows in Java. It was created by LinkedIn and is an open source project.
10. Difference between Task and Callable is that in a Task you can set the result asynchronously.
11. In this example we read data from the disk asynchronously and use that to build a Greeting object. buildFileDataTask (implementation not shown here) reads some file on disk using async I/O and returns a Task<FileData>, where FileData (implementation not shown here) is some abstraction for the data being read. We use FileData to build a Greeting to return to the client.
12. Return ParSeq tasks from methods. These are run by Rest.li using the internal ParSeq engine. Task<T>  if you run this Task using a ParSeq engine it will return you a T eventually.
13. We first read a file on disk using some async I/O abstraction that gives us back a Task for the data read.
14. The basic idea to use ParSeq for Rest.li async method implementations is to return Tasks or Promises. We want to transform the FileData into a Greeting to return to the user. We define a new Task, called mainTask in the example above, to do this. Within the call method of mainTask we obtain the FileData from the fileDataTask. This is a non-blocking call because of the way we assemble our final call graph (more on this in a bit). Finally, we build a Greeting in the buildGreetingFromFileData (implementation not shown here) method.
15. This is what will be returned from the overall method. Tasks.seq is a way to build a call graph between Tasks in ParSeq. In this example we are saying that we want mainTask to run after fileDataTask. This is because mainTask depends on fileDataTask. Once we express our call graph dependency in this way, when we call fileDataTask.get() within the mainTask it will either return right away or throw an exception. This is because ParSeq will make sure that mainTask only gets run AFTER fileDataTask has completed. Tasks.seq() returns a new Task and this Task will get run by the underlying ParSeq engine within Rest.li.
16. This call is blocking because sendRequest returns a Future, and calling get() on the Future waits until the operation has been completed.
17. This is very similar to callback based approached present in Node.js and JavaScript.
18. The first thing we need to do is define the callback that will be executed when the server sends us a response, or there is an error.
19. Then we use the Callback based sendRequest API to send the request. Rest.li invokes the callback for you upon getting a result.
20. Each circle is a response from making a Rest.li request. Each layer represents requests being made in parallel. The yellow circle Is the final result.
21. b1 and b2 don’t depend on each other so theoretically b2 could have been run in the same level as a1, a2, or a3.
22. Use the parseq rest client to create three response tasks.
23. Combine the results from a1-a3 and use that to make another request task b1
24. Similarly combine the results of b1 and b2 and create another request task c1
25. Use the Tasks.seq() and Tasks.par() methods to build the call graph. Within each level we want each Task to run in parallel, which is why we use Tasks.par(a1ResponseTask, a2ResponseTask, a3ResponseTask) and Tasks.par(b1ResponseTask, b2ResponseTask). Finally, we want each level to run sequentially one after the other, which is why wrap everything in a Tasks.seq.