johanandren / futiles Goto Github PK

Hi,

I have a quick question regarding the implementation of Timeouts

It uses under the hood a java.util.Timer to schedule tasks to trigger timeouts.

After some reasearch I have found out that java.util.Timer could be replaced in most cases by a java.util.concurrent.ScheduledExecutorService as it performs better.

There is a bit of info in the javadoc and an interesting stackoverflow questions.

Therefore I performed the change in one my project that also used this kind of trick to design timeouts to see if it works.

I don't have a proper jmh benchmark to back this up but it does seem to perfom better for my use case.

Anyway, I just wanted to let you know about my research and to get your feedback regarding your choice of going with Timer in first place.

Thank you for the nice lib!

Something concise like

val f: Future[Something] = ???

f.withTimeout(10.seconds)

There should be utils for combining multiple futures of different types
A. into a tuple: product(future(1), future(2)) == future((1,2))
B. into a function call: map2(future(1), future(2))((a, b) => a + b) == future(3)
C. into a function call that returns a Future: flatMap2(future(1), future(2))((a, b) => future(a + b)) == future(3)

README

max(try * 2 ^ time_unit, 1) * jitter

Retry.scala

val jitter = 0.5 + rng.nextFloat()
val k = (math.max(1, 2 ^ tries - 1) * jitter).toInt
backOffUnit * k

Are these equivalent?

Consider these cases:

Future { Thread.sleep(5000); false } && Future.successful(false)
Future { Thread.sleep(5000); false } || Future.successful(true)

We could make them resolve as fast as the fastest future, in best case.

Any reason this class shouldn't be made available for public consumption?

Given a block that creates a future a it would be nice to have something that will retry that future if it fails.

For example, given a max number of retries and a predicate to decide if a given exception should lead to retry or not, something like this:

val retryFor = {
  case ex: RetryableException => true
  case _ => false
}
val result: Future[Int] = retry(maxTimes = 3,  decider = retryFor) {
  doSomeFutureStuff(): Future[Int]
}

Not sure what the release story of this project is, but if it publishes to sonatype I can set up sbt-ci-release which has direct integration with sbt-github-actions which would allow you to release new versions of this project just by pushing the appropriate tag to main.

I have done this change to numerous lightbend/akka projects so I know it works.

Many transformations could be done on the calling thread by introducing a calling thread executor.

Docs in master is no good because it will always be out of sync. Should move to github pages.

When support for Scala 2.12 exists

It currently uses for-comprehensions internally, so if the last position fails quickly the result will still have to wait for the previous parameters to complete before failing the resulting future.