Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto recover routine #18

Open
devleste opened this issue Dec 6, 2019 · 1 comment
Open

Auto recover routine #18

devleste opened this issue Dec 6, 2019 · 1 comment

Comments

@devleste
Copy link

devleste commented Dec 6, 2019

I've been using this sdk for roughly 4 months now.

Since day one I suffer from situations where the connected instance simply stop receiving or sending messages, without emitting any error ou timeout events.

The customer sends a message from its device and nothing reaches my server. At the same time, I send a message to a customer and despite the sdk seemingly accepting the command, the message does not reach the customer.

At the moment, this problem is being detected only by observation, after several minutes of failing communications. The workaround is a total script restart, manually.

I can't provide solid evidence because, as I said, no error events are emitted whatsover. A blank log file would do no good here.

The main point here is: there has to be a way to realiably know the integrity of the current connected instance. Maybe some internal periodical routine or a more robust event system that allow us to develop our own routines.

Thanks in advance.

@ceifa
Copy link
Contributor

ceifa commented Mar 11, 2020

When the transport is disconnected, it will try to reconnect 10 times, after that if it fails to reconnect it will throw an error. Have you tried to put a try-catch block to get if any error was thrown?

If no error are been throwed you can enable a trace when building the transport:

.withTransportFactory(() => new WebSocketTransport(undefined, true)) // the second argument means the trace should be enabled

The trace can bring for you more meaningful logs.

However, if you want to build your own routine to check if the connection is alive you can use the listening property inside the blip client instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants