3 ms·
Maximize Server Throughput with Scala Futures
- gopalv 12y agoFuture objects are the simplest way to write these workloads because they map directly to a very simple 2-step model 1) I want this, get started 2) I'll check when I need this, then I'll wait This is what I do when I want to order pizza for pickup and it's easier to debug most of the time - they're only annoying when the pizzas ordered were never picked up (& you get a memory leak, eventually).
- empirewindrush 12y agoThis is wrong. Well not wrong but it doesn't work the way it seems the author thinks it does. For comprehensions de-sugar in a way that isn't really great. See the first answer here. http://stackoverflow.com/questions/19045936/scalas-for-comprehension-with-futures http://stackoverflow.com/questions/19045936/scalas-for-compr... . Basically what he means with that code is: Do four things in parallel and then return the result. What his code ACTUALLY does is do 4 things in sequence in a non-blocking way. This isn't bad (certainly better than blocking for each step) but it misses the real value. He should fire the for futures and then use traverse or Future.sequence to combine them. It is uglier but actually achieves the intended result.
- chowells 12y agoThat is, he's using a monadic interface when an applicative interface is better. Facebook's HAXL project is all about this sort of thing.
- mopierotti 12y agoFair point. The for-comprehension is not quite as magical as I describe it. However, as long as the futures are created outside of the comprehension, the behavior is nearly as described. I'll include a note about it.
- empirewindrush 12y agoCool. Like I mentioned this is still better than the before case. This is a super confusing area of Futures for most people, especially the newer Scala users. I got burnt a couple of times by this. It might not be obvious how creating the future outside of the comprehension changes the behavior the someone new to the topic. This is one of those gotchas that can make Scala frustrating for new users.
- eklavya 12y agoNo, they are right, it would be a sequential operation if the individual steps depended on each other which is not the case. All the four tasks will be computed in parallel and then aggregated to give the result. For comprehensions reduce a lot of syntactic noise and are good to have although you need to make sure that you spawn futures outside of it.
- empirewindrush 12y agoThe issue is that this: val future1 = asyncService1() val future2 = asyncService2() val future3 = asyncService3() val future4 = asyncService4() val resultFuture:Future = for { //For-comprehension r1 <- future1 r2 <- future2 r3 <- future3 r4 <- future4 } yield (someOperation(r1, r2, r3, r4)) looks a lot like this val resultFuture:Future = for { //For-comprehension r1 <- asyncService1() r2 <- asyncService2() r3 <- asyncService3() r4 <- asyncService4() } yield (someOperation(r1, r2, r3, r4)) But the second one will be sequential. This is a common trap for new Scala futures users. You are right (as is the op below) that the first one work the way you expect. It is just easy for new users who don't understand how the de-sugaring resolves for get "caught."
- eklavya 12y agoYeah but that's my point they are doing it right.They are not falling into the trap ;)
- empirewindrush 12y agoYou are right. I jumped on it without giving the author the benefit of the doubt. This is one of those things that I personally have been burned by, and I wanted to save other from falling victim to the same mistake.