Laravel-websockets: broadcasting events from customhandler
I had an entire epistel here on broadcasting from a custom handler on the same socket handler that didn't work, but then I realized why not.
It's the same Eventloop. Meaning the loop is currently executing my broadcast, so it is blocking the server from accepting any new requests. I know Eventloops are supposed to be non-blocking, but it's only that as long as your code does not take it's time.
A solution could be using queues.
I am just going to leave this here, in case some one stumbles on the same issue.
henzeb
All 4 comments
Thanks for posting this. I've been struggling with this for ages now and this seems to make sense. Has anyone managed to find a concrete solution to this yet? I've tried pretty much anything within my power and I wouldn't even know where to begin if I wanted to take a shot at implementing my own queue system.
I hope someone reads this!
joeryoost
on 14 May 2020
Well, from what I understand you will never truly achieve non-blocking with Vanilla PHP, There are several projects that implements threading in PHP. And ofcourse you have the pcntl_fork utilities, but those require you to instantiate a new instance of whatever framework you are using and keep tabs on the child processes to return any responses and to prevent ghost processes.
As for queueing, you can simply use the one laravel has. Just put your long task in a job, and let your client listen for events your job will emit when done.
henzeb
on 15 May 2020
I assume it's related to this: https://github.com/beyondcode/laravel-websockets/issues/366
Currently, the handlers aren't really flexible but will do in the next versions. 馃憖
rennokki
on 13 Aug 2020
I managed to work around this by using queues, as mentioned above. Specifying --sleep=0 with your laravel queue worker ensures practically no latency, so for me this worked like a charm. You could even run a dynamic supervisor process in the background that spins up more queue workers when load increases, so this workaround could even work for larger scale applications.
joeryoost
on 13 Aug 2020
Related issues
sanjayaela
路
4Comments
ElegantSoft
路
4Comments
ElegantSoft
路
3Comments
fridzema
路
4Comments
uncannyMBM
路
5Comments
Most helpful comment
I managed to work around this by using queues, as mentioned above. Specifying --sleep=0 with your laravel queue worker ensures practically no latency, so for me this worked like a charm. You could even run a dynamic supervisor process in the background that spins up more queue workers when load increases, so this workaround could even work for larger scale applications.