Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Gavin Bisesi
    @Daenyth
    let me think

    myFS2ResultsGenerator

    I assume does the results.enqueue1(whatever) yes?

    mn98
    @mn98
    yes, that is simply an fs2 program that takes a queue as an arg (in my contrived example)
    I meant to write "program" :-)
    Gavin Bisesi
    @Daenyth
    so, let me describe your 'pull' side
    what it does is,
    on each implicit request coming in, connect to the existing Queue, dequeueing from it, then stream those into the Ok.chunked
    Try this: Add Stream.eval_(log.info("got request")) ++ results.dequeue...
    than you'll log on each request
    because my suspicion is that the frontend might be doing like long polling
    since nothing in there mentions websockets
    mn98
    @mn98

    on the client side:

        val resultSource = useRef(new EventSource("testResult"))
    
        useEffect(
          () => {
            resultSource.current.onmessage =
              (m: MessageEvent) => {
                println(s"Result element: ${m.data}")
              }
          },
          Seq()
        )

    where that's a scala.js.dom.EventSource

    Gavin Bisesi
    @Daenyth
    so each long poll request would connect to the queue anew
    though, it doesn't really make me understand why it might lose messages
    I know even less about scalajs :)
    mn98
    @mn98
    And as you can see that's a React hook too, so I have a few things going here!
    Gavin Bisesi
    @Daenyth
    I also don't know react :grin:
    strictly a backend dude :p
    mn98
    @mn98
    Play+Slinky(React)+fs2
    Gavin Bisesi
    @Daenyth
    so yeah - next step I'd do is log right before the dequeue action
    mn98
    @mn98
    which up to this point has been an awesome combo to work with... I'm sure there's a way to crack it... ok trying your suggestion...
    Gavin Bisesi
    @Daenyth
    what I'm wondering is, if the frontend sends multiple requests but then leaves it "disconnected" in the backend or something... the dequeue from that stale request would maybe pull a message or two before being closed (idk how play closes those streams), and then those that it pulled would not be visible to new requests
    and if that guess at the sequence is right, it explains your symptom of losing messages
    mn98
    @mn98
    ok, let's see...
    mn98
    @mn98
    hmm, I think you are bang on the money there... I've noticed that I'm getting a "got request" in the console every time the screen renders, so when I change a widget it appears to print it out again. This I changed more stuff and received even fewer elements back.
    Gavin Bisesi
    @Daenyth
    :+1:
    yup ok
    So that's tricky
    very tricky
    How about this:
    in the handler, instead of .dequeue, try using dequeueChunk1
    that gives you an F[Chunk[A]] rather than Stream[F, A]
    You could repeat that with some sleep maybe..
    does that render refresh happen predictably on the frontend?
    Would it be acceptable for that to be the only way you get more messages?
    because that would be easier
    if not as ideal
    ideally, it would be a long-lived websocket request, and you could cleanly connect the "close" logic
    but idk how play's support for such things is, and your frontend would have to do the other side similarly
    mn98
    @mn98
    yes, it happens somewhat predictably in that any time an action is performed on the front end I see the "got request" message
    after the first 'run' the browser appears to hang and I see lots of ERR_CONNECTION_RESET and ERR_CONNECTION_REFUSED related to the 'testResult' route
    Play has both SSE and websocket... I went with SSE because I thought it would safer/simpler/easier!
    mn98
    @mn98
    There's a nice example of a chat server with Play Scala using web sockets and that works great, perhaps I need to hijack that if I want to have this permanently open connection. Then presumably I'll be able to take my fs2 results and convert it to akka without too much trouble...
    I know nothing about web sockets but it should be fun at least
    thank you very much for your help!
    Gavin Bisesi
    @Daenyth
    :+1:
    yeah, this is less of a streamz problem than a play one
    mn98
    @mn98
    Well by golly I had one last desperate shot... and by moving the client side 'EventSource' out of the react component and into the main for {} yield {} it appears to work and I receive all elements
    Gavin Bisesi
    @Daenyth
    oh yeah, that makes total sense too
    that's basically what I was getting at with using a Stream[F, MyRoutes] construction
    main would run that stream