def func1(list : List[T]) : Future[\/[Throwable,Unit] ]
def func2(list : List[T]) : Future[List[\/[Throwable,Unit]]]
where T is just a specific type and that type will be same for both the functions. Now func2 is dependent on success of first func 's future. so func2 should run sequentially only after func completed successfully. I want a for comprehension something in a similar line as below (following isn't valid compilable code) and return Future[\/[Throwable,Unit] ]
def func3 combiner(list) : Future[\/[Throwable,Unit] ] = for{
u <- func1(list)
us <- u
d <- func2(list)
}yield
Any pointers how to go about this?
Because futures either complete with a value or an exception you won't need the Either (or do you have other reasons for using it?).
Running this code should help you (and reading the documentation on futures):
import scala.concurrent._
import ExecutionContext.Implicits.global
def f1(l: List[Int]): Future[Int] = future { println("f1"); l head }
def f2(l: List[Int]): Future[Int] = future { println("f2"); throw new Exception("bang") }
def f3(l: List[Int]): Future[Int] = future { println("f3"); l last }
val result1 = for {
x1 <- f2(List(1, 2))
x2 <- f1(List(1, 2)) // f1 is not run
} yield x2
val result2 = for {
x1 <- f1(List(1, 2))
x3 <- f3(List(1, 2))
} yield x3
result1.onComplete(res => println("result1 = " + res))
result2.onComplete(res => println("result2 = " + res))
Related
I have two Future functions:
def parseIntFuture(str: String) = Future{scala.util.Try(str.toInt).toOption}
def divideFuture(a: Int, b: Int) = Future{ if (b == 0) None else Some(a / b)}
And now I want connect them and eventually get a Future[Option[Int]] type result which is the second one's return value, but if I do like this:
def stringDivideBy(aStr: String, bStr: String) = {
val x = for {
aNum <- parseIntFuture(aStr)
bNum <- parseIntFuture(bStr)
} yield (aNum, bNum)
x.map(n => {
for{
a <- n._1
b <- n._2
} yield divideFuture(a, b)
})
}
Actually I will get Future[Option[Future[Option[Int]]]] instead of Future[Option[Int]] only. I know it's because I'm passing one Future to the other, but I don't know what is the correct way to connect these two Futures one by one avoiding using Await. I halt explicitly use Await, then what would be the solution?
You don't need monad transformers and other "heavy artillery" for simple stuff like this. The general rule is don't make your code more complex than it absolutely has to be.
(parseIntFuture(foo) zip parseIntFuture(bar))
.flatMap {
case (Some(a), Some(b)) => divideFuture(a, b)
case _ => Future.successful(None)
}
There is this thing called OptionT monad transformer that solves exactly this problem. With OptionT, your code would look somewhat like
import cats.data.OptionT
// ...
val x = (for {
aNum <- OptionT(parseIntFuture(aStr))
bNum <- OptionT(parseIntFuture(bStr))
res <- OptionT(divideFuture(aNum, bNum))
} yield res).value
and return a Future[Option[Int]].
You could avoid monad transformers at the cost of nested for-comprehensions:
import scala.concurrent._
import scala.concurrent.ExecutionContext.Implicits.global
def parseIntFuture(str: String) = Future{scala.util.Try(str.toInt).toOption}
def divideFuture(a: Int, b: Int) = Future{ if (b == 0) None else Some(a / b)}
def stringDivideBy(aStr: String, bStr: String): Future[Option[Int]] = {
for {
aOpt <- parseIntFuture(aStr)
bOpt <- parseIntFuture(bStr)
resOpt <-
(for {
a <- aOpt
b <- bOpt
} yield divideFuture(a, b))
.getOrElse(Future { None })
} yield resOpt
}
Let's say I have a function func1 that needs to return a Future with two integers. Each of the two values are returned by independent futures, like so:
def f1 = Future { 1 }
def f2 = Future { 2 }
def func1 : Future[(Int,Int)] = {
val future1 = f1
future1.map { result1 =>
result1 * 10
}
val future2 = f2
future2.map { result2 =>
result2 * 20
}
}
I need future1 wait until future2 ends (or vice versa) to return both results as (Int,Int). How can this be accomplished?
That's precisely what the zip method on futures does:
val futurePair: Future[(Int, Int)] = future1.zip(future2)
Note that if you haven't instantiated your futures before (say, if future1 and future2 are defs, not vals), this will run the two computations in parallel, while a for comprehension (or flatMap) would wait for the first one to succeed before starting the second one.
A for-comprehension is the best option here:
scala> import scala.concurrent.Future
import scala.concurrent.Future
scala> import concurrent.ExecutionContext.Implicits.global
import concurrent.ExecutionContext.Implicits.global
scala> def f1 = Future{1}
f1: scala.concurrent.Future[Int]
scala> def f2 = Future{2}
f2: scala.concurrent.Future[Int]
scala> for {result1 <- f1; result2 <- f2} yield (result1 * 10, result2 * 20)
res0: scala.concurrent.Future[(Int, Int)] = scala.concurrent.impl.Promise$DefaultPromise#71f67a79
More information can be found here and here.
Note: this will run the two Futures in sequence while Cyrille Corpet's solution will run them in parallel.
You can use a for-comprehension for futures that have already started like this:
val f1: Future[Int] = ???
val f2: Future[Int] = ???
val f3: Future[Int] = ???
val futureInts: Future[(Int, Int, Int)] = for {
result1 <- f1
result2 <- f2
result3 <- f3
} yield (result1, result2, result3)
If the futures were assigned to lazy vals or defs then this wouldn't work, because the futures would not have been started (if you start the futures inside the for comprehension, then they will be executed sequentially). Here is an example of starting them, and then waiting for them with for.
Example:
val f1: Future[Int] = Future {
println("starting f1")
Thread.sleep(1000)
1
}
val f2: Future[Int] = Future {
println("starting f2")
Thread.sleep(3000)
2
}
val f3: Future[Int] = Future {
println("starting f3")
Thread.sleep(2000)
3
}
val futureInts: Future[(Int, Int, Int)] = for {
result1 <- f1
result2 <- f2
result3 <- f3
} yield (result1, result2, result3)
futureInts.map {
case tuple => println(tuple)
}
Output:
starting f1 // These first
starting f3 // threes statements
starting f2 // happen right away.
(1,2,2) // Then this prints a three seconds later
In your case you could do this:
def func1 : Future[(Int,Int)] = {
// Start futures
val future1 = f1.map(_ * 10)
val future2 = f2.map(_ * 20)
// Wait for both futures, and return a tuple
for {
result1 <- future1
result2 <- future2
} yield (result1, result2)
}
How is functions with side-effects best handled in for-comprehensions in Scala?
I have a for comprehension that starts by creating a kind of resource (x) by calling a function f1. This resource has a close-method that needs to be called at the end but also if the for-comprehension fails somehow (unless.
So we have something like:
import scala.util.{Try,Success,Failure}
trait Resource {
def close() : Unit
}
// Opens some resource and returns it as Success or returns Failure
def f1 : Try[Resource] = ...
def f2 : Try[Resource] = ...
val res = for {
x <- f1
y <- f2
} yield {
(x,y)
}
Where should I call the close method? I can call it at the end of the for-comprehension as the last statement (z <- x.close), in the yield-part, or after the for-comprehension (res._1.close). None of them ensures that close is called if an error occurs (e.g. if f2 fails).
Alternatively, I could separate
x <- f1
out of the for-comprehension like this:
val res = f1
res match {
case Success(x) => {
for {
y <- f2
}
x.close
}
case Failure(e) => ...
:
That would ensure the call of close but is not very nice code.
Is there not a smarter and more clean way to achieve the same?
When I have such problem I decide between 2 possibilities:
Use Scala ARM
Implement Loan Pattern on my own (link is volatile and could die)
In most cases I prefer own implementation to avoid additional dependency.
Here is the code of Loan Pattern:
def using[A](r : Resource)(f : Resource => A) : A =
try {
f(r)
} finally {
r.close()
}
Usage:
using(getResource())(r =>
useResource(r)
)
Since you need 2 resources you will need to use this pattern twice:
using(getResource1())(r1 =>
using(getResource2())(r2 =>
doYourWork(r1, r2)))
You can also look on following answers:
Scala: Disposable Resource Pattern
functional try & catch w/ Scala
Using a variable in finally block
A common pattern for closing resources is the loan pattern:
type Closable = { def close(): Unit }
def withClosable[B](closable: Closable)(op: Closable => B): B = {
try {
op(closable)
} finally {
closable.close()
}
}
With a little refactoring you can use this pattern:
import scala.util.{Try,Success,Failure}
trait Resource {
def close() : Unit
}
// Opens some resource and returns it as Success or returns Failure
def f1(res: Resource) : Try[Resource] = ???
def f2(res: Resource) : Try[Resource] = ???
val f1Resource: Resource = ???
val f2Resource: Resource = ???
val res = for {
x <- withClosable(f1Resource)(f1)
y <- withClosable(f2Resource)(f2)
} yield {
(x,y)
}
or
import scala.util.{Try,Success,Failure}
trait Resource {
def close() : Unit
}
// Opens some resource and returns it as Success or returns Failure
def f1: Try[Resource] = {
val res: Resource = ???
withClosable(res){ ... }
}
def f2: Try[Resource] = {
val res: Resource = ???
withClosable(res){ ... }
}
val res = for {
x <- f1
y <- f2
} yield {
(x,y)
}
You could use
https://github.com/jsuereth/scala-arm
If your "resource" does not implement java.io.Closeable (or some other closable interface, supported by than library) you just need to write an implicit conversion:
implicit def yourEnititySupport[A <: your.closable.Enitity]: Resource[A] =
new Resource[A] {
override def close(r: A) = r.commit()
// if you need custom behavior here
override def closeAfterException(r: A, t: Throwable) = r.rollback()
}
And use it like this:
import resource._
for {
a <- managed(your.closable.Enitity())
b <- managed(your.closable.Enitity())
} { doSomething(a, b) }
Given:
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
def f: Future[Either[String, Int]] = Future { Right(100)}
def plus10(x: Int): Future[Either[String, Int]] =
Future { Right(x + 10) }
I'm trying to chain the Future[...] together as so:
scala> for {
| x <- f
| y <- for { a <- x.right } yield plus10(a)
| } yield y
<console>:17: error: value map is not a member of Product with
Serializable with
scala.util.Either[String,scala.concurrent.Future[Either[String,Int]]]
y <- for { a <- x.right } yield plus10(a)
^
I am expecting to get: Future{Right(100)} as a result, but I get the above compile-time error.
Travis Brown gave an excellent answer on how to use Monad Transformers to fix my code here. However, how can I fix my code without Monad Transformers?
Turns out that I can use Either#fold:
scala> for {
| a <- f
| b <- a.fold(_ => Future { Left("bad") }, xx => plus10(xx) )
| } yield b
res16: scala.concurrent.Future[Either[String,Int]] =
scala.concurrent.impl.Promise$DefaultPromise#67fc2aad
scala> res16.value
res17: Option[scala.util.Try[Either[String,Int]]] =
Some(Success(Right(110)))
I was about to answer when yours appeared, but you might still look at this:
val res = for {
x <- f
y <- x.fold(x => Future{Left(x)}, plus10)
} yield y
It is a little more concise on the right side and keeps the left side.
Suppose I need to run two concurrent computations, wait for both of them, and then combine their results. More specifically, I need to run f1: X1 => Y1 and f2: X2 => Y2 concurrently and then call f: (Y1, Y2) => Y to finally get a value of Y.
I can create future computations fut1: X1 => Future[Y1] and fut2: X2 => Future[Y2] and then compose them to get fut: (X1, X2) => Future[Y] using monadic composition.
The problem is that monadic composition implies sequential wait. In our case it implies that we wait for one future first and then we will wait for another. For instance. if it takes 2 sec. to the first future to complete and just 1 sec. to the 2nd future to fail we waste 1 sec.
Thus it looks like we need an applicative composition of the futures to wait till either both complete or at least one future fails. Does it make sense ? How would you implement <*> for futures ?
None of the methods in other answers does the right thing in case of a future that fails quickly plus a future that succeeds after a long time.
But such a method can be implemented manually:
def smartSequence[A](futures: Seq[Future[A]]): Future[Seq[A]] = {
val counter = new AtomicInteger(futures.size)
val result = Promise[Seq[A]]()
def attemptComplete(t: Try[A]): Unit = {
val remaining = counter.decrementAndGet
t match {
// If one future fails, fail the result immediately
case Failure(cause) => result tryFailure cause
// If all futures have succeeded, complete successful result
case Success(_) if remaining == 0 =>
result tryCompleteWith Future.sequence(futures)
case _ =>
}
}
futures.foreach(_ onComplete attemptComplete)
result.future
}
ScalaZ does a similar thing internally, so both f1 |#| f2 and List(f1, f2).sequence fail immediately after any of the futures fails.
Here is a quick test of the failing time for those methods:
import java.util.Date
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
import scalaz._, Scalaz._
object ReflectionTest extends App {
def f1: Future[Unit] = Future {
Thread.sleep(2000)
}
def f2: Future[Unit] = Future {
Thread.sleep(1000)
throw new RuntimeException("Failure")
}
def test(name: String)(
f: (Future[Unit], Future[Unit]) => Future[Unit]
): Unit = {
val start = new Date().getTime
f(f1, f2).andThen {
case _ =>
println(s"Test $name completed in ${new Date().getTime - start}")
}
Thread.sleep(2200)
}
test("monadic") { (f1, f2) => for (v1 <- f1; v2 <- f2) yield () }
test("zip") { (f1, f2) => (f1 zip f2).map(_ => ()) }
test("Future.sequence") {
(f1, f2) => Future.sequence(Seq(f1, f2)).map(_ => ())
}
test("smartSequence") { (f1, f2) => smartSequence(Seq(f1, f2)).map(_ => ())}
test("scalaz |#|") { (f1, f2) => (f1 |#| f2) { case _ => ()}}
test("scalaz sequence") { (f1, f2) => List(f1, f2).sequence.map(_ => ())}
Thread.sleep(30000)
}
And the result on my machine is:
Test monadic completed in 2281
Test zip completed in 2008
Test Future.sequence completed in 2007
Test smartSequence completed in 1005
Test scalaz |#| completed in 1003
Test scalaz sequence completed in 1005
The problem is that monadic composition implies sequential wait. In our case it implies that we wait for one future first and then we will wait for another.
This is unfortunately true.
import java.util.Date
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
object Test extends App {
def timestamp(label: String): Unit = Console.println(label + ": " + new Date().getTime.toString)
timestamp("Start")
for {
step1 <- Future {
Thread.sleep(2000)
timestamp("step1")
}
step2 <- Future {
Thread.sleep(1000)
timestamp("step2")
}
} yield { timestamp("Done") }
Thread.sleep(4000)
}
Running this code outputs:
Start: 1430473518753
step1: 1430473520778
step2: 1430473521780
Done: 1430473521781
Thus it looks like we need an applicative composition of the futures to wait till either both complete or at least one future fails.
I am not sure applicative composition has anything to do with the concurrent strategy. Using for comprehensions, you get a result if all futures complete or a failure if any of them fails. So it's semantically the same.
Why Are They Running Sequentially
I think the reason why futures are run sequentially is because step1 is available within step2 (and in the rest of the computation). Essentially we can convert the for block as:
def step1() = Future {
Thread.sleep(2000)
timestamp("step1")
}
def step2() = Future {
Thread.sleep(1000)
timestamp("step2")
}
def finalStep() = timestamp("Done")
step1().flatMap(step1 => step2()).map(finalStep())
So the result of previous computations are available to the rest of the steps. It differs from <?> & <*> in this respect.
How To Run Futures In Parallel
#andrey-tyukin's code runs futures in parallel:
import java.util.Date
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
object Test extends App {
def timestamp(label: String): Unit = Console.println(label + ": " + new Date().getTime.toString)
timestamp("Start")
(Future {
Thread.sleep(2000)
timestamp("step1")
} zip Future {
Thread.sleep(1000)
timestamp("step2")
}).map(_ => timestamp("Done"))
Thread.sleep(4000)
}
Output:
Start: 1430474667418
step2: 1430474668444
step1: 1430474669444
Done: 1430474669446
Your post seems to contain two more or less independent questions.
I will address the concrete practical problem of running two concurrent computations first. The question about Applicative is answered in the very end.
Suppose you have two asynchronous functions:
val f1: X1 => Future[Y1]
val f2: X2 => Future[Y2]
And two values:
val x1: X1
val x2: X2
Now you can start the computations in multiple different ways. Let's take a look at some of them.
Starting computations outside of for (parallel)
Suppose you do this:
val y1: Future[Y1] = f1(x1)
val y2: Future[Y2] = f2(x2)
Now, the computations f1 and f2 are already running. It does not matter in which order you collect the results. You could do it with a for-comprehension:
val y: Future[(Y1,Y2)] = for(res1 <- y1; res2 <- y2) yield (res1,res2)
Using the expressions y1 and y2 in the for-comprehension does not interfere with the order of computation of y1 and y2, they are still being computed in parallel.
Starting computations inside of for (sequential)
If we simply take the definitions of y1 and y2, and plug them into the for comprehension directly, we will still get the same result, but the order of execution will be different:
val y = for (res1 <- f1(x1); res2 <- f2(x2)) yield (res1, res2)
translates into
val y = f1(x1).flatMap{ res1 => f2(x2).map{ res2 => (res1, res2) } }
in particular, the second computation starts after the first one has terminated. This is usually not what one wants to have.
Here, a basic substitution principle is violated. If there were no side-effects, one probably could transform this version into the previous one, but in Scala, one has to take care of the order of execution explicitly.
Zipping futures (parallel)
Futures respect products. There is a method Future.zip, which allows you to do this:
val y = f1(x1) zip f2(x2)
This would run both computations in parallel until both are done, or until one of them fails.
Demo
Here is a little script that demonstrates this behaviour (inspired by muhuk's post):
import scala.concurrent._
import scala.concurrent.duration._
import scala.concurrent.ExecutionContext.Implicits.global
import java.lang.Thread.sleep
import java.lang.System.{currentTimeMillis => millis}
var time: Long = 0
val x1 = 1
val x2 = 2
// this function just waits
val f1: Int => Future[Unit] = {
x => Future { sleep(x * 1000) }
}
// this function waits and then prints
// elapsed time
val f2: Int => Future[Unit] = {
x => Future {
sleep(x * 1000)
val elapsed = millis() - time
printf("Time: %1.3f seconds\n", elapsed / 1000.0)
}
}
/* Outside `for` */ {
time = millis()
val y1 = f1(x1)
val y2 = f2(x2)
val y = for(res1 <- y1; res2 <- y2) yield (res1,res2)
Await.result(y, Duration.Inf)
}
/* Inside `for` */ {
time = millis()
val y = for(res1 <- f1(x1); res2 <- f2(x2)) yield (res1, res2)
Await.result(y, Duration.Inf)
}
/* Zip */ {
time = millis()
val y = f1(x1) zip f2(x2)
Await.result(y, Duration.Inf)
}
Output:
Time: 2.028 seconds
Time: 3.001 seconds
Time: 2.001 seconds
Applicative
Using this definition from your other post:
trait Applicative[F[_]] {
def apply[A, B](f: F[A => B]): F[A] => F[B]
}
one could do something like this:
object FutureApplicative extends Applicative[Future] {
def apply[A, B](ff: Future[A => B]): Future[A] => Future[B] = {
fa => for ((f,a) <- ff zip fa) yield f(a)
}
}
However, I'm not sure what this has to do with your concrete problem, or with understandable and readable code. A Future already is a monad (this is stronger than Applicative), and there is even built-in syntax for it, so I don't see any advantages in adding some Applicatives here.
It needs not be sequential. The future computation may start the moment the future is created. Of course, if the future is created by the flatMap argument (and it will necessary be so if it needs the result of the first computation), then it will be sequential. But in code such as
val f1 = Future {....}
val f2 = Future {....}
for (a1 <- f1; a2 <- f2) yield f(a1, a2)
you get concurrent execution.
So the implementation of Applicative implied by Monad is ok.