by

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
Ross A. Baker
@rossabaker
We register an async timeout handler to complete a callback to race against the response.
Fabio Labella
@SystemFw
why does it behave differently than what you expected?
ah, I guess it shouldn't fail
Ross A. Baker
@rossabaker
It behaves exactly like I expect, and I can't make it behave like I need to.
Fabio Labella
@SystemFw
but succeed with fa
I'm confused then
what behaviour do you want it to have?
what I mean is that I'm unclear is what you've written is the behaviour you see or the behaviour you want
Ross A. Baker
@rossabaker
I want the f in the first argument to race to run before fa can complete, but I still want to race those two effects.
Fabio Labella
@SystemFw
Deferred[F, Unit].flatMap { gate =>
  F.race(F.async(cb =>  gate.complete(()) *> f(cb)), gate.get *> fa)
}
Ross A. Baker
@rossabaker
Concretely, I want to addListener on the servlet's AsyncContext before anything else can complete() it.
I thought about Deferred. I'd also like to cancel the right if the left wins.
Fabio Labella
@SystemFw
Not entirely bullet proof, if fa is super fast
Ross A. Baker
@rossabaker
Oh, that's a little different than what I was trying. Hmm.
Fabio Labella
@SystemFw
I think the canceling behaviour is embedded in race already
Ross A. Baker
@rossabaker
Yeah, I wasn't thinking of burying a race inside the Deferred.
Fabio Labella
@SystemFw
the deferred inside the race you mean
it can still fail
if fa completes after during the left hand side *>
but that's unavoidable unless you can be more granular in your f
Ross A. Baker
@rossabaker
Could run f(cb) before the gate.complete()
Fabio Labella
@SystemFw
i.e. complete the gate when the registration is done, but before the part you want to race
if you ran f(cb) before, you won't be racing anymore, no?
well, I guess it depends on the f
Ross A. Baker
@rossabaker
asyncF(cb => F.delay(f(cb)).guarantee(gate.complete))
Fabio Labella
@SystemFw
right, it depends on f
Ross A. Baker
@rossabaker
The real f is asyncContext.addListener(new AsyncTimeoutHandler(cb))
Fabio Labella
@SystemFw
if f calls cb and then goes on to do other things asyncly, then yes
Ross A. Baker
@rossabaker
Yes, exactly.
I think this is what we need.
Fabio Labella
@SystemFw
yeah, I think that works then
Ross A. Baker
@rossabaker
Writing a test for this issue is a huge pain.
Fabio Labella
@SystemFw
yeah
Ross A. Baker
@rossabaker
It only happens under load, and as asynchronous logging in a Jetty-owned thread.
Fabio Labella
@SystemFw
yeah, sounds beautiful
Ross A. Baker
@rossabaker
I added a unit test to ensure I didn't break the happy path and have a manual reproduction.
Even the unit test sucks, because I can't pass around a Clock in this world. It's wall-time timeouts in a scheduler I don't own.
Fabio Labella
@SystemFw
ah, that sucks
I have a similar situation in upperbound because I haven't migrated to TestContext yet
forget about running that on CI with any semblance of reproducibility
Ross A. Baker
@rossabaker
Yeah, I'm afraid this is going to be the next generation of our flaky Travis tests.
I can make it less flaky by waiting longer and increasing the run time of every build.
Maybe we can port jetty to cats-effect. :trollface:
Fabio Labella
@SystemFw
heh, I tinkered with those two knobs (how flexible each test should be, and how long do I want the whole suite to run ) for ages :joy:
same thing for fs2 retry, until those tests are ported as well (I think we turned them off altogether )
Ross A. Baker
@rossabaker
Is fs2 RC still on track?
I guess I should ask there.
Fabio Labella
@SystemFw
yes it is
two PRs
and I want to add an absolutely trivial combinator as well, if I get the time