Live host still running on Linux backend when web client has closed.

[shiblydangdang]

Hi

Can someone confirm that the following is correct please?

Web client uses SignalR to connect to the Harmony Core dotnet core application on IIS in our case.

Harmony Core app uses SSH to connect to our HCHOST.DBR on Linux.

We have four scenarios for exiting the web application.........

1. Navigate away from the app to a different website.
2. Close the browser tab.
3. Click our logout option.
4. Close the browser.

All of the above options fire the OnDisconnectedAsync event and then call our backend subroutine to tidy up licenses etc. Perfect so far.

The problem we have is that somehow the web app is being closed but the SSH and HCHOST.DBR are still live on the Linux box.

We cannot replicate this on our development and testing servers but it is happening often on customer site.

Can anyone please suggest anything to help us understand how this can be happening?

Thanks

[hippiehunter]

Is the leftover process considered a zombie by Linux? Also what version of Linux are you deploying on?

[shiblydangdang]

No, these are not considered zombies.

We've had HCHOST.DBR processes where the parent pid is 1 but this is not what we are seeing on customer site.

We are seeing HCHOST.DBR processes that have a valid parent pid but as far as we know the web application has closed.

Local Linux servers are Redhat Enterprise 6 or 8.10

Customer server is Redhat Enterprise 8.10

[shiblydangdang]

I've just thought, these processes should still have a live BRIDGE log file so I'm just going to check those.

[shiblydangdang]

Just found this occurring very often in customer BRIDGE logs but we are not seeing this on local servers.......

Dispatcher: Reading ContentLength from inputContent-Length: 64^M
:21
Dispatcher: starting callblock processing with ContentLength 64 ContentType ^M
{
Dispatcher: Reading 65 total bytes of Content from input
Dispatcher: Reading 63 bytes from input
Dispatcher: Parsing buffer {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":233}}
Dispatcher: Finished Json Parsing
Dispatcher: Single Call
Dispatcher: requestid -1
Dispatcher: method target was $/cancelRequest
ReportError: Notify -> SYNERGEX.SYNERGYDE.ROUTINENOTFOUND: $/cancelRequest was not found
at HARMONY.TRADITIONALBRIDGE.ROUTINEDISPATCHER.PROCESSCALLBLOCK(@SYSTEM.TEXT.JSON.JSONELEMENT,@JSON.DISPATCHSERIALIZER)I in RoutineDispatcher.dbl:line 8.1133

[hippiehunter]

Is there a configuration difference between the two deployments? is one talking direct to child processes and the other is operating over ssh (including locally)?

[shiblydangdang]

Both are using ssh.

[hippiehunter]

if there's no PII involved, can you collect a core dump for one of the stuck processes and send it + your actual dbr/dbs executable from the synergy install. I think you have my email any thing with an executable will need to be on google drive/onedrive/dropbox otherwise the email will get filtered out

[shiblydangdang]

Yes, will do. Thanks Jeff.

[hippiehunter]

I think I found an ordering bug during shutdown if there is an active call at the moment you decide to shutdown the host. I'll see if i can get a build made/released tomorrow.

[shiblydangdang]

Thanks for the update.

Will this explain the issue with cancelRequest too? If not, do you know where we should start looking for that as it's still happening often on customer site?

Dispatcher: Parsing buffer {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":233}}

[hippiehunter]

yes, the cancelRequest thing is fully tied to the issue

[shiblydangdang]

That sounds like good news then thanks.

Do you know why we aren't seeing it on our servers? Would be useful to know what the customer is doing differently.

[hippiehunter]

Sorry for the delay, the latest packages should solve this

[yinghuangfcl1]

After updating to latest Harmony Core, I received following error when compiling:

Compiling Traditional Bridge library code...
11.362 foreach data item in value.Items() as @StringDictionary.KeyValuePair
%DBL-E-INVSTX, Invalid syntax
%DBL-E-WRILIT, Writing to a literal or missing argument
11.364 if(item.Value .is. String) then
%DBL-E-NFND, item.Value not found
%DBL-E-NOOBJ, No object file created