search

beyondcode / laravel-websockets

Websockets for Laravel. Done right.
https://beyondco.de/docs/laravel-websockets
MIT License
5.07k stars 627 forks source link

websocket serve stops working after a minute (ssl) #64

Closed aleex1848 closed 4 years ago

aleex1848 commented 5 years ago

laravel/framework 5.7.19 beyondcode/laravel-websockets 1.0.3 php-fpm 7.2.12

I got everything working with ssl by following the very nice documentation. Now when i start the websocket server everything seems to be working fine:

But after a minute it stops working. Dashboard looses connection. Reconnect results in:

Are there any debugging possibilities? I can't see nothing atm...thanks !

srirag1987 commented 5 years ago

I am using Let's Encrypt SSL configured in a project, the same happens in mine also. WebSocket opening handshake timed out after certain period of time.

'local_cert' => "/etc/letsencrypt/live/domain.com/fullchain.pem", /*

aleex1848 commented 5 years ago

I tried to use nginx as reverse proxy and updated my code. But there is no change regarding my problem (websockts stoping after a minute). I noticed that after broadcasting an event the cpu load of websockets:serve process is going to 100% for a while and things stop working. After a minute or two it throws exceptions like: `[2019-01-02 13:19:07] local.ERROR: {"exception":"[object] (Illuminate\Broadcasting\BroadcastException(code: 0): at /var/www/my-app/201812191346 59/vendor/laravel/framework/src/Illuminate/Broadcasting/Broadcasters/PusherBroadcaster.php:117) [stacktrace]

0 /var/www/my-app/20181219134659/vendor/laravel/framework/src/Illuminate/Broadcasting/BroadcastEvent.php(48): Illuminate\Broadcasting\Broadcaste

rs\PusherBroadcaster->broadcast(Array, 'statistics-upda...', Array)` so something regarding statistics-update seems to be failing.

So i disabled statistics both in config/websockets.php: enable_statistics => false and in public/js/app.js for the laravel-echo client: disableStats: true

With disabled statistics websockets are working fine and stable now.

stayallive commented 5 years ago

^ are you using a seperate app for just the websockets by any chance?

The statistics use the Broadcasting features of Laravel, if that's not correctly configured (which it could possibly be on a seperated instance) it will crash on not being able to broadcast the event (to itself).

bam-tbf commented 5 years ago

I had the same issue as @aleex1848 and the same fix worked. It would be nice to know what is causing the problem so I could reenable statistics. It was a very confusing bug! Thanks for the suggestion.

@stayallive, I'm my case I am not using a separate app for websockets. I am using horizon to queue broadcast websocket events, but it all originates in the same Laravel web app. So to clarify, I run

I configured laravel-websockets to be proxied by nginx using a separate domain as well like this, so that I could use nginx to provide SSL layer for laravel-websockets: https://ma.ttias.be/deploying-laravel-websockets-with-nginx-reverse-proxy-and-supervisord/

Now it is all working fine.

BTW, it would be nice if the routes used by laravel-websockets were configurable (at least a prefix). It would help to use nginx as a proxy without the need for a second domain for the websocket routes, so that the right routes could be forwarded to the websocket port. As it is, the use of /app and /apps is general enough to cause conflicts in many laravel apps.

Similarly, it would be great if the dashboard could be authenticated and pointed to a different domain and port so it could be used externally in this configuration as well.

stayallive commented 5 years ago

It would be interesting to see a bit more context about the actual exception.

https://github.com/laravel/framework/blob/5459ac15b56cdee8e176827ddbb30357119ceabb/src/Illuminate/Broadcasting/Broadcasters/PusherBroadcaster.php#L117-L119

Looking at how or why it's thrown it can be for two reasons, it either got an error while sending (which can also show up in the php artisan websockets:serve log) or could not connect at all.

However, disabling the statistics works and I assume that normal broadcasting events (again, assuming you are using https://laravel.com/docs/5.7/broadcasting in your app, correct me if wrong) are working... I'm guessing the server is somehow not happy with the event and the exception should contain the error response or the php artisan websockets:serve output shows an exception before it exits.

About the paths, I agree although it's a lot better with the configurable path for the dashboard and the option to set your own middleware from the config. However I needed a bit more so I just used my own WebsocketsServiceProvider to setup the paths how I wanted them. (don't forget to disable autodiscover for the package so you can register your custom service provider, and also add the facade manually if you need it)

About the /app(s) prefix, I think that cannot be changed because the Pusher SDK's expect that path and it's not configurable. So changing the websocket/api routes would require a modified SDK. You can just use the same domain and run your websockets proxy on a different port (like 6001 for example), since your app runs on 80/443 that will not conflict and you won't need a seperate subdomain and also can still use nginx to proxy the traffic.

A bit off-topic, but feel free to open an feature request issue / pr if you think it's needed / possible.

bam-tbf commented 5 years ago

@stayallive Thanks for helping to investigate/resolve this.

To answer your question, yes other event broadcasting is working in the app without problem.

The only exceptions/errors that showed up were the BroadcastExceptions in the laravel server logs, just like aleex1848 showed above, while the CPU maxed out at 100% for the php artisan websockets:serve process until I killed it. No error/exception in php artisan websockets:serve log file.

Let me know if I can provide any other information.

Thanks for the suggestion on WebsocketsServiceProvider. Good to know that is possible, but may be more/more involved than most users would need/want.

Also good to know about /app(s) being required for Pusher. That's fair. You are correct that I could use the same domain and port 6001 for SSL for the websocket. I was hoping to only have to have ports 80/443 open on the server for security, but its not too bad to have 6001 also open.

stayallive commented 5 years ago

@bam-tbf no problem ofcourse, however I'm a bit out of idea's on why this might be happening since it looks like a "regular" broadcast message seems to get stuck except it always is the statistics-updated one (?), which is not very special/big/heavy... if anyone has some ideas on how to reproduce or what might cause this would be great!

Some more context around the Exception (from Sentry etc. for example) could possibly also help to see what the heck is going on... but really not sure right now.

bam-tbf commented 5 years ago

Ok, thanks. We will just leave stats disabled for now. Hopefully someone else will have information or ideas on what the cause or contributing factors are.

kotenarok commented 4 years ago

Any updates on this issue?