Before Migration a question according pusher-js / reconnection issues #314
Replies: 2 comments 1 reply
-
FWIK, Pusher's JS library is trying to reconnect exponentially to the server in case of unknown disconnections. These disconnections are not accounted for if they are server-based (for example, when soketi is closing, it sends the On transition to offline, you might want to listen for these events and try to disconnect and connect on Pusher automatically. In the meanwhile, the connection will still be opened for 120 more seconds in the server, but it will be ejected after this period of time. I'm pretty sure it how you're handling the connection on the device using the Pusher SDK. |
Beta Was this translation helpful? Give feedback.
-
Hi Renokki, thank you very much for the answer. I self gave me a little fresh-up , what happens to this reconnect-issue since 2019 and saw My feeling: to detect the transition or the interpreting / counting by pusher-js is not always given, as there So my little question, (and hope), is there any chance to use on the frontend-side |
Beta Was this translation helpful? Give feedback.
-
In my actual Webapp i am Using laravel-echo with socket.io 2.3 and on the backend laravel 8, and tladverdure laravel websocket on a dedicated server (redis, horizon for communication / eventing..)
Two Years go i tested the beyondcode laravel-php-based websocket server with the pusher-js connector instead of socket.io and there was a major issue with reconnection after the third disconnection from pusher-js to the websocket service.
After many, many hours of testing and workarounds the final conclusion was, that pusher-js is the culprit;
My Issue / Discussion to this issue:
beyondcode/laravel-websockets#163
all those "i find a solution" where not stable and pusher-js was often calling "home" (pusher origin service) instead of
the service websocket service.
So i switched back and the combination socket.io 2.3 <-> tladverdure is working still stable.
Your soketi Server sounds really great, cudos!, an bevor a big migration may you can test your stack
easy against this issue:
after doing this 3-times, pusher-js didnt reconnect to the websocket server automatic .. it "says" that
it is reconnecting, but with the wrong server ...
Has (your) solution - (or better say pusher-js still) the same issue ?
If yes, is there a possibility to use socket.io (4) instead of the pusher-js ?
This would be great and many thanks.
Beta Was this translation helpful? Give feedback.
All reactions