I understand that SignalR continually attempts to reconnect if a connection fails for any reason. What's the best way to test my server and client's response to this?
ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available.
Since a browser is limited to six connections, we can try to manually monitor how many connections are supported by a given browser.
hub. stop(). done(function() { alert('stopped'); });
SignalR takes advantage of WebSocket, an HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fall back to other techniques and technologies when it isn't, while the application code remains the same.
In order for the Client to try to reconnect, you need to configure the HubConnectionBuilder with the withAutomaticReconnect method. The JavaScript code looks something like this:
const connection = new signalR.HubConnectionBuilder()
.withUrl(`${apiUrl}/subscribe/change`)
.withAutomaticReconnect()
.build();
Once that is set, the client will try to reconnect when the connection is lost.
Internally, when SignalR is disconnecting, it calls the stopInternal
function.
If you want to do some manual testing to make sure that your handlers are being fired and they do what you expect them to do. You can save the connection in a const
and fire the events yourself.
What I did:
window
object. window.signalR = connection;
Network conditions
.Network throttling
to offline.signalR.connection.stopInternal();
And my onreconnecting
handler started firing. It runs 4 times by default. It looks like this:
connection.onreconnecting(error => {
console.log('Reconnecting interval', error);
});
NOTE: This strategy is for development and some manual testing only. I wouldn't recommend using the window
object for unit tests or integration tests.
A similar strategy can be achieved by caching your connection on some internal variables to be used by unit tests.
I found a solution here: https://stackoverflow.com/a/59916046/2929675
Before the WebSocket connection gets opened, you must execute this script to monkey patch the browsers WebSocket function:
const sockets = [];
const nativeWebSocket = window.WebSocket;
window.WebSocket = function(...args){
const socket = new nativeWebSocket(...args);
sockets.push(socket);
return socket;
};
Now you have access to all WebSocket connections via the sockets array. And when you want to trigger a reconnect, you can call
sockets[0].close();
using the index of the connection you want to close.
When SignalR automatic reconnect is enabled, it will automatically try to open a new connection, and the Reconnecting
and Reconnected
events get fired.
It's a bit hacky, but it's the best solution I have found so far.
It looks like there is also some progress in the chromium issue to support this in the dev tools: https://bugs.chromium.org/p/chromium/issues/detail?id=423246
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With