Problem with OnDisconnectedAsync

[shiblydangdang]

Hi

We seem to be randomly having an issue with OnDisconnectedAsync.

When the user closes the browser, we need to call a backend subroutine to tidy up our license table.

We've currently got a signalr call back to HC to do this and so far it seems to have been working fine. However, we recently had a customer have issues with license slots not being cleared. We managed to replicate the issue but only on the Firefox browser. The customer is using Edge but we can't replicate it on Edge, Chrome or Safari.

We tried moving the process into the OnDisconnectedAsync method but it still seems to fail. We think it's killed the HCHOST.DBR process before it gets to the clear job slot call.

Can you please advise if we should be able to do this in the OnDisconnectedAsync or do we need another option?

Thanks

[hippiehunter]

I dont think we're a good source for per browser signalR debugging.

As for any Traditional Bridge specific behaviors, does the process actually keep running holding the license? If it doesnt keep running, does the license free itself up after 20 minutes? The exit flow for TB processes involves requesting the stop nicely, then waiting before terminating it, its not a particularly long wait so we can maybe extend it somewhat.

[shiblydangdang]

Thanks for the info.

The dbr process stops and releases the synergy license no problem.

The issue is, it seems to stop before we have chance to call our subroutine to release our license.

Can you please tell me how I can extend the wait as it's easy to test the issue this end?

[hippiehunter]

Its not easy to extend the wait it will require a new harmony core build. from your new description this isnt actually the problem.

Take a look at the signalr template https://github.com/Synergex/HarmonyCore/blob/master/Templates/SignalR/SignalRHub.tpl and help me understand specifically where you've tried to put your custom shutdown code

[shiblydangdang]

Sorry I'm away from my laptop but hopefully I can explain.....

public override async method OnDisconnectedAsync, @task
ex, @exception
proc
parent.OnDisconnectedAsync(ex)
data contextObject, @object
if(Context.Items.TryGetValue("RPCContext", contextObject))
begin
data callContext = ^as(contextObject, @<INTERFACE_NAME>Service)
if(callContext != ^null)
begin
callContext.aspLogout
_contextFactory.ReturnContext(callContext)
end
end
endmethod

If I try from postman it works nicely every time.

I've put some logging in our low level routine and it stops logging part way through when it fails which made me think the dbr is stopping.

[hippiehunter]

The DBR isnt going to stop until the ReturnContext call is made. im not sure if this is a simplification because you're answering from a phone , but its critical that aspLogout be awaited otherwise ReturnContext will run effectively at the same time

[shiblydangdang]

Yes, sorry, I did do await.

If you're saying this is the correct way to do this, then I will try again and see what's happening.

It seems strange that it works differently on different browsers. That's what's adding to the confusion my side!

[shiblydangdang]

Hi Jeff

I've spent a bit more time on this and I'm still confused.

If I connect from postman and make a few signalr calls then disconnect, I can debug and see it stopping in the OnDisconnectedAsync method every time.

Problem is when we disconnect from our web app, it never stops in the method. This is what we use to disconnect within our Angular code.......

public async SRLogout() {
if (this.connectionActive) {
// Send logout message before closing the connection
await this.aspLogout();
}

try{
  await this.hubConn?.stop().then(success =>  this.connectionActive = false)
  console.log("Successfully closed SignalR connection. Connection Active: " + this.connectionActive);
}
catch(ex){
  console.error("We had an issue closing the SignalR connection. -> " + ex);
}

}

Can you think of anything else I can do/check or anything we could be doing wrong?

Thanks

[hippiehunter]

You might need to use something like fiddler to purposefully man in the middle your connections. Given you get the right behavior from postman watch that connection in fiddler, then do the same thing from your angular app. Compare for differences. Unfortunately if this works properly from postman, I really don't think there's much I can tell you to do on the server side.

[shiblydangdang]

Thanks Jeff. I'll give this a go.