Aspnetcore: HubConnectoin on close listener remove

[mashahbazi]

Is your feature request related to a problem? Please describe.

having persist connection

Describe the solution you'd like

provide remove onClose listener

Additional context

Hi
When I working with SignalR .Net (not core) (java client for android) the best practice for having persist connection was stopping hubConnection when state changed to reconnecting and start new hubConnection.
Now in SignalR .Net core (java client for android) I use onClose listener and stop then start new hubConnection. Is better idea for having persist connection??
If not with this practice onClose trigger to many times so if you can provide some methods to remove onClose listener it help to user it better.

[BrennanConroy]

the best practice for having persist connection was stopping hubConnection when state changed to reconnecting and start new hubConnection.

I've never heard of this.

What scenario do you have that requires removing the onClose handler? Would using a bool/check in the handler solve your issue?

[mashahbazi]

I've never heard of this.
I get this practice from WebSocket and use it in signalR and it help me to my connection more persist.Before it my connection wasn't reliable and it was on connection slow state and I lose my signals

I don't want my added listener for onClose on HubConnection that I stop trigger any more.yes I use bool for start ,checking connection state but this still cause some bugs for me. for example when I reset my server I have too many connection's. I add to many check and finally I can stop all connection except one but I want start just one siganlR. Removing onClose help me at this work

[halter73]

If not with this practice onClose trigger to many times

Are you adding an onClose handler during each reconnect? Do you have to do that if so?

[mashahbazi]

Are you adding an onClose handler during each reconnect? Do you have to do that if so?

yes I have to because I start new hub I must handle new hub on Close

[halter73]

Could you instead just rely on the old hander to handle the new hub on close? It might require some indirection, but it seems like that should be possible. Alternatively could you recreate the HubConnection when you reconnect?

That's not to say that we shouldn't allow you to remove the old onClose handler. I'm just suggesting workarounds for now.

[mikaelm12]

Are you registering different handlers? If not then you could just not re-add the call back when you stop and start a connection. This is the same behavior we have in out JS client. You can register multiple onClosed handlers and they don't get cleared when the HubConnection is stopped and restarted. I think being able to remove onClosed handlers though is something we should consider.

Some options

More involved - We could have the callback registration method return a disposable that when disposed removes the callback from the list of callbacks.

Less involved - We could change the implementation to only allow registering a single onclosed callback. So registering a second callback would overwrite the previous one. So removing callbacks would mean registering a no-op callback.

[jdnichollsc]

It would better having the option to remove onclose listener, to avoid unnecessary events registered in memory, memory leaks, etc
What do you think folks?

[msftbot[bot]]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!