Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Gabriel Volpe
@gvolpe
And this works well
Not sure what the differences are with FunSpec
Gavin Bisesi
@Daenyth
class MySpec extends FunSpec {
  describe("stuff") {
    it("does the thing") {
      assert(1 + 1 == 2)
    }
  }
}
Gabriel Volpe
@gvolpe
I just published Chapter 7 which is dedicated but didn't talk about this because I didn't have the need, maybe I should :)
class MySpec extends AsyncFunSuite {

   forAll { (a: A, b: B) =>
      test(s"myTest for $a and $b") {
        IO(assert(true)).unsafeToFuture
      }
   }

}
This is combining Scalatest with Scalacheck
You can do that Resource trick without issues (here at least)
Mmm I think you're right, it works but it doesn't release the resource properly @Daenyth
Gavin Bisesi
@Daenyth

it doesn't release the resource properly

Can you elaborate? I haven't seen that issue

and yeah scalacheck is super awkward because forAll wants => Unit
Gabriel Volpe
@gvolpe
Yeah there's an open issue to support async tests from 2015 or so, never happened
I mean with this approach I just described, tests run well (trying some integration tests) but the resource doesn't seem to be released properly
It seems random though
(trying to reproduce it now)
Okay here's what's happening, I run my integration tests using a single resource.use { allMyTestsHere }.unsafeRunSync without issues
My resource is a connection to PostgreSQL
If I shutdown the Postgres server, I get this on the SBT console
sbt:shopping-cart> java.lang.Exception: Fatal: EOF before 5 bytes could be read.Bytes
        at skunk.net.BitVectorSocket$$anon$2.$anonfun$readBytes$1(BitVectorSocket.scala:72)
        at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:139)
        at cats.effect.internals.IORunLoop$RestartCallback.signal(IORunLoop.scala:355)
        at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:376)
    at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:316)
    at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:136)
    at cats.effect.internals.IORunLoop$RestartCallback.signal(IORunLoop.scala:355)
    at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:376)
    at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:316)
    at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:136)
    at cats.effect.internals.IORunLoop$RestartCallback.signal(IORunLoop.scala:355)
    at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:376)
    at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:316)
    at cats.effect.internals.IOShift$Tick.run(IOShift.scala:36)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
This doesn't happen if the resource is released once the test is done using it
Gavin Bisesi
@Daenyth
hmm
too many variables vs the cases I've seen work for me to pinpoint the issue :(
Gabriel Volpe
@gvolpe
Yeah Idk, we need a better test framework (/cc @kubukoz flawless... emm)
Jakub Kozłowski
@kubukoz
no pressure at all! :D
it's a no-framework!
Marcin Wadoń
@marcinwadon

Hey all! :)
I'm using IOApp and I have such a loop:

  def manager: IO[Unit] =
    IO.unit // for simplicity
      .flatTap(_ => logger.info("Scheduling next update round"))
      .flatMap(_ => IO.sleep(10 seconds))
      .flatTap(_ => logger.info("Next iteration"))
      .flatMap(_ => manager)

def run(): IO[ExitCode] =
    manager.map(_ => ExitCode.Success)

I'm running it through sbt, then pressing Ctrl+c gives me:

[info] running o.c.NetworkLoadBalancer
[ioapp-compute-0] INFO o.c.lb.Manager - Scheduling next update round

[warn] Canceling execution...
[error] Total time: 14 s, completed Nov 18, 2019 8:01:22 PM
sbt:cl-lb> [ioapp-compute-1] INFO o.c.lb.Manager - Next iteration
[ioapp-compute-1] INFO o.c.lb.Manager - Scheduling next update round
[ioapp-compute-2] INFO o.c.lb.Manager - Next iteration
[ioapp-compute-2] INFO o.c.lb.Manager - Scheduling next update round
[ioapp-compute-3] INFO o.c.lb.Manager - Next iteration
...

Any idea why it's not been cancelled?

Gavin Bisesi
@Daenyth
Could be sbt
try using sbt run instead of executing it from sbt shell
Paul Snively
@paul-snively
Also, there's some sbt flag about ctrl-c...
Marcin Wadoń
@marcinwadon
Running directly as sbt run gives me:
➜  cllb git:(master) ✗ sbt run
...
[ioapp-compute-0] INFO o.c.lb.Manager - Scheduling next update round
^C
[warn] Canceling execution...
[error] Total time: 12 s, completed Nov 18, 2019 8:11:59 PM
[warn] Run canceled.
[error] (run-main-0) java.lang.InterruptedException
Exception in thread "sbt-bg-threads-1" java.util.concurrent.RejectedExecutionException
    at java.util.concurrent.ForkJoinPool.externalSubmit(ForkJoinPool.java:2328)
    at java.util.concurrent.ForkJoinPool.externalPush(ForkJoinPool.java:2419)
    at java.util.concurrent.ForkJoinPool.execute(ForkJoinPool.java:2648)
    at scala.concurrent.impl.ExecutionContextImpl.execute(ExecutionContextImpl.scala:24)
    at sbt.internal.BackgroundThreadPool$BackgroundRunnable.$anonfun$cleanup$1(DefaultBackgroundJobService.scala:390)
    at sbt.internal.BackgroundThreadPool$BackgroundRunnable.$anonfun$cleanup$1$adapted(DefaultBackgroundJobService.scala:389)
    at scala.collection.immutable.List.foreach(List.scala:392)
    at sbt.internal.BackgroundThreadPool$BackgroundRunnable.cleanup(DefaultBackgroundJobService.scala:389)
    at sbt.internal.BackgroundThreadPool$BackgroundRunnable.run(DefaultBackgroundJobService.scala:359)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
[error] java.lang.InterruptedException
[error]     at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:998)
[error]     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
[error]     at cats.effect.internals.IOPlatform$.$anonfun$unsafeResync$2(IOPlatform.scala:51)
[error]     at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
[error]     at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:62)
[error]     at scala.concurrent.package$.blocking(package.scala:124)
[error]     at cats.effect.internals.IOPlatform$.unsafeResync(IOPlatform.scala:51)
[error]     at cats.effect.IO.unsafeRunTimed(IO.scala:324)
[error]     at cats.effect.IO.unsafeRunSync(IO.scala:239)
[error]     at cats.effect.internals.IOAppPlatform$.main(IOAppPlatform.scala:24)
[error]     at cats.effect.IOApp.main(IOApp.scala:67)
[error]     at cats.effect.IOApp.main$(IOApp.scala:66)
[error]     at o.c.NetworkLoadbalancer$.main(NetworkLoadbalancer.scala:12)
[error]     at o.c.NetworkLoadbalancer.main(NetworkLoadbalancer.scala)
[error]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[error]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[error]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[error]     at java.lang.reflect.Method.invoke(Method.java:498)
[error] stack trace is suppressed; run last Compile / bgRun for the full output
[ioapp-compute-1] INFO o.c.lb.Manager - Next iteration
[ioapp-compute-1] INFO o.c.lb.Manager - Scheduling next update round
[ioapp-compute-2] INFO o.c.lb.Manager - Next iteration
[ioapp-compute-2] INFO o.c.lb.Manager - Scheduling next update round
...
^C
[warn] Thread[shutdownHook1,5,run-main-group-0] loading cats.effect.internals.CancelUtils$ after test or run has completed. This is a likely resource leak
Marcin Wadoń
@marcinwadon
here is the min code to reproduce it
object App extends IOApp {

  val logger = Slf4jLogger.getLogger[IO]

  def manager: IO[Unit] =
    IO.unit
      .flatTap(_ => logger.info("Scheduling next update round"))
      .flatMap(_ => IO.sleep(10.seconds))
      .flatTap(_ => logger.info("Next iteration"))
      .flatMap(_ => manager)

  override def run(args: List[String]): IO[ExitCode] =
    manager.map(_ => ExitCode.Success)
}
Gavin Bisesi
@Daenyth
er I wonder if sbt run as a single command has the same issue as when running from the shell
Marcin Wadoń
@marcinwadon
/\
same issue as written above
Gavin Bisesi
@Daenyth
sbt assembly and run that maybe, or if you have native-packager sbt stage and run that. Or Intellij and right click the class > run
Marcin Wadoń
@marcinwadon
we've checked and it's not the case once running as standalone jar
fork := true and outputStrategy := Some(StdoutOutput) made the job for sbt
Daniel Spiewak
@djspiewak
so Global / cancelable := false should disable the ctrl-c madness.
the problem here is that there's not a lot that we can reliably do inside of cats-effect
we could in theory catch the InterruptedException and turn it into a cancelation
that could result in canceling your program, which would be the right thing to do in this case
but it's not the right thing to do in all cases
InterruptedException can mean several things depending on the circumstances, and we really don't have a good way of knowing which it is
one thing we could do, and I would accept a PR for this, would be to try to detect running inside of sbt and then make the emergency handler for InterruptedException (sitting on the thread pool) cancel the main fiber
it would be a bit tricky to do that without throwing out the main thread though
so it's like… rough
and that won't necessarily be enough to fix it because a different thread could be active that we don't necessarily control
but at least that would give some slightly better ergonomics
basically, native interruption isn't a real thing on the JVM, and it somewhat annoys me that sbt pretends that it is
Jakub Kozłowski
@kubukoz
didn't sbt 1.3.x make cancelation bearable?
Daniel Spiewak
@djspiewak
actually it created this problem