I’m testing server-side events with Plug’s send_chunked/2 and chunk/2 but I also receive data from a stream. Due to the latter detail I decided to implement the receiving of the streamed data in a GenServer, the request is made with HTTPoison and it is similar to what is mentioned in this StackOverflow post, although I receive the chunk data in a slightly different format (still a non-JSON string with a data key), and had to also implement a handle_info callback for messages with a %HTTPoison.AsyncEnd{} struct.
Other than that it’s working and the GenServer is started from my controller. So essentially I have a controller that receives a request, then spins up a GenServer that makes another request, receives streamed data and has to send the data parsed back to the original connection.
The issue comes when trying to send the data back from the GenServer. I tried passing the conn struct to the genserver and calling Plug.Conn.chunk/2 from it but it seems that Cowboy recognized that a separate process sends a messages, raises a warning and then the GenServer stops processing. The Cowboy warning raised is here in the Cowboy code: [warning] Received message #{message inspected} for unknown stream 1. (or another stream ID, but generally integers 1 to 3).
As Cowboy spawns a process for each request I assume it expects that responses should be sent from this process which is what is causing this issue. I’ll probably implement a receive loop without spawning a different process to handle this, but I was wondering if I’m not missing or misunderstanding something and if there isn’t a way to send a response with Plug (Cowboy) from a separate process, in this case a GenServer.
This will likely sound uniformed, still I can’t help but wonder why do you need a separate process (a GenServer in your case) to fetch stuff from outside at all?
Sounds like the caller will still have to wait i.e. the request is blocking, right? If that’s true then I see no value in using one more process.
But if I haven’t understood correctly and the request is not blocking then you’ll likely have more luck with wrapping your solution around a Phoenix Channel.
The request is blocking, yes. And you’re probably right, I likely don’t need a GenServer, but I wanted to abstract as much as I can in a separate module and as it has to receive messages by instinct I started with a GenServer. What I think I’ll do is just wrap the receive loop and parsing of streams in a separate module and call it from my controller and it will be with one process as you say. But I was also just curious about this Cowboy detail.
You can still do that but the abstraction doesn’t need be on a process level, it can just be functions in a separate module that get called directly in the context of the web requests’ process.
I too wouldn’t want a 100-line pattern-matching clauses soup capturing the state machine of calling an external API right inside my Phoenix controller function so good job there, you are on the right path.
I might have been misreading various blog posts and news but it seems the writing is on the wall that Cowboy will eventually be abandoned in favor of Bandit. Cowboy has legitimate problems with scaling, pooling and data copying (if I remember correctly!) and Bandit aims to fix (part of) those.
I’d recommend to spawn a process, send the data chunks back to the original process, and run a receive loop in the original process to catch the data and then send to the conn. Processes are cheap on the BEAM, and you would like to have some abstraction.
